Everybody Is Different

Different people view things slightly differently. The paper clip that shows up in a common word processor can be annoying or entertaining. A seemingly great idea for a user interface can turn out to be not so great since the system's users might have vastly different viewpoints than the system's developers.

People look at problems and solutions differently. I prefer to get an overview of a solution so that I can appreciate how the problem has been addressed. Examining a rough diagram of the major classes and a few sequence diagrams provides me information more quickly than wading through code.

Not everyone feels the way I do. Some people prefer to read the code. Viewing a class diagram provides no benefit to them. It is just noise. Neither approach is necessarily better or worse than the other is. The only time you will run into trouble is if you do not appreciate both approaches when you encounter a person who does it the other way.

Likewise, developers have a spectrum of preferences that run the gamut from strongly typed languages to nontyped languages and from big design up front to no design up front. Those on one end of the spectrum should appreciate the tradeoffs and context issues of those on the other end.

In addition, the guidelines presented in this book might be radically different from your current development paradigm. Comparing them to your own guidelines can help you to understand the tradeoffs made in your paradigm and may spur changes in your guidelines.