I have to agree almost entirely with Simon Judge's criticism of the original article there. Anyone who's actually tried what Morten is advocating will find that the project wasted 2 or 3 months at the beginning designing details when they didn't have sufficient knowledge of the problem.

In my opinion (obviously I agree it depends on the project size, but assuming a small to medium project - large ones should be broken down into a series of small projects!) doing a quick prototype and then throwing it away and designing the real thing is likely to get the best result.

Unfortunately this usually only happens when some of the developers have done the "prototype" as a real project for someone else. With time to market pressures as they usually are, when the prototype mostly works someone always wants to turn it into the real thing as quickly as possible - producing a maintenance nightmare!

Mark

Agile approach would help here, too, I think. Breaking down the features to smaller tasks, the milestone(s) to few weeks long sprints would enable prototyping, which is essentially what the customer also wants. We just have to convince them!

As to Simon's comment on the easiness of committing breaking code to source code repository, Continuous Integration could help here. Using a background service whose sole purpose is to "digest" newly committed code and let the team know the build result _instantly_ is really efficient.