What is Design

Laurent Bossavit has written one of his thought-provoking articles, this time on design.

Anyone who has worked with any of the CASE tools knows the problem: you create your initial design using the tool, quite possibly UML diagrams. The first step of coding can be easy: press a button and code gets generated. Within a short time, however, programmers do their work. Questions arise that weren't considered before and the answers to them affect the source code directly. There are details and addtional features that were never in the initial design. Nearly all commercial CASE tools boast the ability to round-trip, that is to automatically update their design models based o nthe code. They never seem to work.

This isn't because of programmer laziness (thought that is a factor). David Parnas famously called UML the undefined modeling language. Compared to code, any design language is ambiguous. Not only that, but some things that really matter are most naturally conveyed using a programming language.

To me, design is all about making decisions and communicating those decisions. Usually it's considered a highly technical task, the responsibility of the development team. Having read Eric Evans' book, I believe it can be useful (sometimes essential) to share responsibility for design with domain experts.

In some ways, the idea of a Ubiquitous Language comes close to a universal design or, better, a way of talking about design. If the application is to be useful in its business domain, it really helps to have a coherent way of talking about what it does in the language of the business domain.

On the other hand, there are technical decisions to be made that fall outside the scope of the business domain. Those decisions are best expressed in different languages.

All of which leads me to think that there can never really be one design. Depending on who is talking and at what level of detail, the needs are different. Some people are more comfortable with visual diagrams than text and vice versa. (I tend to prefer text, mostly because I have yet to find software that makes editing diagrams with a mouse anything less than painful.) Programmers like source code; domain experts are unlikely to understand it.

The touchiest question of all is who gets to do design. The agile answer is usually the whole team. That means devolving power to the lowest level, so that the most junior programmer has a say in decisions that affect the success or failure of the project. It is asking quite a lot of the team to pull together to make good decisions and hold by them.

However, the alternative of decisions handed down from on-high, from analysts or architects or even team leads doesn't necessarily work all that well. For one thing, it's bad for morale. For another, if the decision doesn't take all relevant factors into consideration, it may have to be worked around or even subverted in order to get anything working at all. Inflexible decisions made at the start of a project pose serious risks.

A computer program embodies design decisions in a way that no other document can. 1 Decisions will be made at the coalface, even if nothing has been specified at a higher level. If earlier decisions are unworkable, they may be quietly overturned in the code.

[1]That's a reason why unit tests are popular as design documents: they are highly specific, relevant and clear. A unit test suite is as like any other bad design document, but it can be seen as such by applying normal coding standards. A team that can write competent code can write competent unit tests. (That's not always the true of UML or English for that matter.)