22 August 2005

Spolsky and software design

Joel Spolsky has written yet another article claiming up-front design is the best way to develop software.

I think there are two grains of salt to be aware of when reading this article.

First, Joel is a very smart guy, and purposefully goes out to hire the smartest developers he can find. Great developers tend to have great skills in designing software, and seeing problems up-front. I'd say this isn't the case for all teams/developers, and on average most initial designs tend to suck.

Second, Joel is the customer and the developer in this example. Real customers rarely have such a clear idea of their requirements at the specification stage.

This aside, I still disagree with his argument. His main example of where up-front design helped him was this:

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule.

In this example, Joel's attitude that code will be difficult to change is self-fulfilling. Because he designs up-front, he believes his code is not likely to change, therefore he writes it in such a way that it is difficult to change. If you don't spend a lot of time on design up-front, and instead concentrate on making the code easy to change (refactoring, testing), you can deal with changes like this even when you don't recognise them at the start.

So while up-front design will help you change your system cheaply in the design phase, if you don't make your software easy to change and continue designing while you're developing, you won't be able to change your system cheaply later in the process.

I should also point out that agile methods don't say "don't design", but rather "do enough design so you can proceed with coding and get some real feedback about whether your design works". This is a common misunderstanding that Joel seems to be propagating in this article.