What Does "Design" Mean for Software?

Most software practitioners would agree that good design is important. The trick is agreeing on what constitutes "good design." Clearly, different people will have different ideas of what is "good" -- that adjective is subjective and hard to quantify. More surprising is that there is no general agreement even on what "design" means.
When you are producing toasters, it's much clearer. The design probably comprises detailed mechanical drawings of the parts to be manufactured, an electrical schematic, and parts lists for off-the-shelf components. If you're looking at one of those artifacts, you are not likely to be confused about whether you're examining part of an actual toaster or a design for a toaster.

With software, it's much more confusing. Consequently, we have a wider range of opinions about what would be the "design" of the software as opposed to the implementation of that design (the software itself). To illuminate the problem, let's look first at a real-world example.

There are tools that will reverse-engineer the source code you have written, and produce detailed UML diagrams. In many cases, you can go both directions: make a change to the UML model, and the tool generates code for you; change the code and the model is updated. You might consider those the "as-built specifications" for your software. They are a 2-dimensional graphical model of your code structure. But is that really a "design"? You can produce the UML without ever interacting with a modeling tool, perhaps without ever sketching a single line on a whiteboard or cocktail napkin. Just point the tool at your finished code, and voila! You may have never gone through anything remotely resembling a design process, and you can still have a "UML design" view into your code.

There’s nothing wrong with using such tools if they’re useful for your project. But I would argue against automatically treating their output as a "design". In my view, there are a few key criteria that must be met before you can call something a design:

• It reflects intentional, intelligent thought about how something should be built
• It precedes (at least in its initial instance) the production of the item itself
• It presents a higher level of abstraction, and offers insight beyond what you could obtain by looking directly at the end product itself.
  

The last bullet in that list tends to be the sticking point. When a model is detailed enough to produce the final, working code, it doesn't present any useful abstraction. It may be helpful to view the product that you have built via a graphical model, but that doesn't mean you have a design. Design is a more thoughtful, deliberative process, and must to some degree present an abstraction or idealization of reality.

The second bullet point can be controversial as well. I would contend, however, that if the artifacts a team claims to be your "design" are wholly produced after the fact, it’s not much of a design. The best claim one can make is that perhaps the original design was wholly in each of its creators' minds, but even so it would be preferable to capture those thoughts in a slightly abstracted model, instead of reverse-engineering a highly detailed model from the final production.

As we gauge the appropriate level of abstraction for software design, it is also important to consider the audience. Who will use the design, and what will they produce from it? Here, it's dangerous to follow the manufacturing analogy too far. That will be the subject of a future posting.

The Death of Software Engineering?

Tom DeMarco recently made quite a stir with an article in IEEE Software (July/Aug, 2009). Despite his own history as an influential thought-leader in software engineering, he now suggests that perhaps the very idea of software engineering has outlived its usefulness. The value of control, furthermore, depends inversely on the value of the project itself. In other words, “strict control is something that matters a lot on relatively useless projects and much less on useful projects.”

Needless to say, the idea was controversial, and unleashed a torrent of letters in response. There has long been a creative tension between software development as a rigorous scientific discipline, and the more romantic notion of software developer as artist or craftsman, with passionate debate on both sides. My own viewpoint tends to fall somewhere in the middle, and I found DeMarco’s article especially moving, because it suggests a willingness to abandon orthodoxy in favor of pragmatic reality.

One aspect of conventional wisdom that DeMarco challenges is his own earlier statement that “you can’t control what you can’t measure.” It’s a catchy statement, and oft-quoted. Certainly, it’s hard to argue against measuring the critical parameters for your project if you have a practical means of doing so. But life is full of counter-examples as well. As my wife and I interact with our daughter, we establish guidelines and boundaries. Her compliance isn’t measured in any scientific way, yet she’s not “out of control.” Similarly, I’ve experienced success in guiding projects without measuring every aspect of the outcome that is important: Typically cost and schedule are measured quantitatively, but code quality may be more subjective. Metrics can be useful, but not necessarily essential, depending on the type of project.

I am reminded of a linguistics professor I heard lecture in the 1980s (I wish I could remember his name -- it was a great lecture!). He was challenging the opinion held by many that we don’t really know something unless we can put it in words. As a counter-example he cited an instance where his young grandson went missing. He knew vividly what the boy looked like, and would have recognized him in an instant. Nevertheless, it was difficult to describe him precisely in words for the missing persons report. It often seems to be the case that we know something when we see it (high-quality software design, for example), even if we cannot quantify a metric to prove our case.
I hope the end result of Tom DeMarco’s skeptical article will be greater openness and flexibility. As software developers, we have many tools at our disposal. We can be craftsmen and engineers at the same time. Embracing one end of the spectrum doesn’t exclude us from the other.