subbu.org

I just finished reading "Hackers and Painters". I did not find most of the chapters in the middle of the book inspiring or thought-provoking. Towards the end though, one particular statement stopped me from flipping the page:

Design begins by asking, who is this for and what do they need from it.

I could not agree more. If the initial designer does not understand who is going to use the software and why, the design and architecture has few chances to survive and evolve.

Don’t we always start with the use cases? Right. In software design exercises, the team responsible for the software almost always starts with the use cases from users’ perspective, and then arrives at the broad structure of the software and the bits and pieces that make it up. But that is not enough.

I would like to look at this statement in a broader sense, and include all the people who will directly or indirectly work with the software during its lifetime. Besides the end users, several other people come in contact with the software.

There are folks who write tests for the software. Can they write meaningful tests? Does the design lend to testable implementation? If not, there is a problem with the design.

Then there are folks who maintain the software. The "designer" may want to use all sorts of esoteric techniques to make the software look "elegant", or "cool". It does not matter if other people who want to fix a few things here and there cannot understand the structure of the code and therefore cannot easily maintain it. I have seen software where the original author used all sorts of "cool" techniques he learned, only to find that everyone that had to fix bugs hated the code because they all found that it was too difficult to find out what was happening where. There are all kinds of design patterns and OO techniques in the code, but the original author forgot about users. In this case, the users are the folks who had to fix bugs. Needless to say, one of the folks who was tasked to fix a few bugs went ahead to refactor portions of the code and rewrote the rest.

Another group of users are the folks that manage the software after it is deployed. Can these folks tune the software to keep it healthy? Can they upgrade it to later versions easily? Can they monitor the software? If any of these tasks are difficult, they will not like to use it, and will want it replaced with something that they can manage.

Good design is not just about using the right programming language, right technology, right design patterns, and right tools. Designing good software also involves understanding all these kinds of users that come in contact with the software. None of these users will have the time to ponder on how well the original designer used all the "right" things if they cannot do their tasks well enough with the software. You see, they use their own standards, and not the designer’s standards to judge how well the design of the software is.