Emergent Design vs Early Prototyping

Emergent Design vs. Early Prototyping - Software Reality

However, early prototyping (used correctly) provides many of the benefits of an agile approach (for example early feedback), whilst retaining the more rigorous benefits gained from designing a system before coding it up.


This article seems to forget all about XP's Spike Solution phase. In this phase, if the solution to a problem is unknown, it's OK to do a Spike Solution. This is a quick test of a small slice of an application to prove, or figure out, what and where the pieces of an application might be. For instance, if there is a new persistence layer that might be nice to use, test it out in a Spike Solution.

This seems to be sort of the ideas behind the article. I disagree with the article on a few points. For example, time is always important on projects. You never have time enough. Why waste it on prototyping code to throw it out? By using XP's other tenets (unit testing, constant refactoring) the beginning code is as good as the end code. No need to throw out an entire prototype.

Note that a Spike might be thrown out, but it's OK because it's a very small slice of the app.

From practical experience, every prototype solution always gets deployed to production. Why not, from the start, treat all code as production?
Post a Comment

Popular posts from this blog

Converting Array to List in Scala

I ported a JavaScript app to Dart. Here's what I learned.

Minification is not enough, you need tree shaking