In his recent blog post “Build one to throw away” Udi Dahan is addressing the chicken-and-egg problem software developers often face. On one hand, customers don’t exactly like what they want so that they need to closely interact with software engineers. On the other hand, building production-ready solutions for this interaction might lead to high costs. Or, as the author explains,
While there is value in building real functionality on top of your production infrastructure to learn more about the challenges in doing that and in that process, refining the API of your platform, baking more capabilities into it, etc, the problem is that you are slowing down the important learning of what system needs to be built.
Thus, Dahan recommends to “build one to throw away”. For such a prototype engineers should not use TDD, DDD, CQRS, Event Sourcing, SOA, and so forth. And when creating the prototype, architects should at least know the most important use cases that are architecturally significant and build a “just enough architecture upfront”. One of the challenges in this context are organizations that have difficulties understanding the difference between prototypes and production-ready code.
Dahan closes with
Efficiency is secondary to effectiveness. You want to make sure your headed in the right direction before putting the pedal to the metal. Rework is to be accepted and, yes, even embraced.
His posting received a couple of comments from readers.
For example, Jonathan Oliver agrees:
I totally agree-especially with efficiency being subordinated to effectiveness. In fact, Stephen Covey, author of the 7 Habits of Highly *Effective* People mentioned how we run in the name of efficiency and this causes all kinds of problems whereas being effective is what was really needed.
Jonathan Atting says:
Great post. Initially the best prototypes are often prototypes done in a mockup language. Not only that everyone sees that it’s a prototype to be thrown away, but one will get much better and more radical improvement suggestions. If the prototype looks like a real thing feedback is mostly on the GUI, like size and position on buttons. But in the end, one will not get the real validation feedback until the users start using it in their real environment.
Nightwatch thinks, prototyping also bears some risks:
This advice is quite dangerous imho – as soon as you get the client excited and ready to move forward you pull a brake instead and say: “not so fast guys, now we have to start programming from scratch – we’ll be ready in four months and we’ll continue from where we are now”. How’s that supposed to work – your client will think you’re wasting his time and destroying what’s been accomplished so far, so you not only discourage them but also give them more time to change their requirements. When you finally show up with your ‘production software’ they will want something else.
