CTO Articles
IT World
E-Business in the Enterprise – March 09, 2004
Rapid application development and the art of throwing things away
By Sean Mc Grath
One of the great - but often uncelebrated - capabilities computers give us, is the ability to make mistakes more quickly.
Tools such as spreadsheets, databases with screen painters, HTML form designers, programming languages IDEs all have dual roles in the application development process. The obvious role they share is to allow us to computerize our designs as quickly as possible. The less obvious role they share is that they help us shake the mistakes out of our designs as quickly as possible. To take best advantage of the latter capability, it is necessary to adopt a form of development and of team management which on the face of it, is contrary to common sense.
Over to Fred Brooks, author of the all-time classic software development book 'The Mythical Man Month'[1]:
"Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow."
It deserves to be read twice, especially the last sentence. Plan to throw one away; you will anyhow.
Here is a variation on the same theme. I don't know who this is attributable to but it too, deserves to be read twice:
"Every system needs to be designed twice. Once to design it. Then again to design it the way it should have been designed in the first place."
Now obviously these two blanket statements need to be nuanced in the real world. They do not always apply, but they apply more often than not in my experience.
If you manage a team of developers who go straight to low level code to draw screens, forge database queries or transform XML documents you should consider the benefits that might accrue if you encourage your team to "play" with their ideas using rapid application development tools for a while before getting down to serious coding. You may find they are already doing it covertly anyhow. Bring it out into the open. Actively encourage the idea of building one to throw away. Scary though it may seem at the outset, the result is likely to be better software, faster. Yes, there will be a period of what looks in management speak like 'negative productivity' but remember. software development is a mix of art and science [2].
Developers for their part, can be afraid of the 'build one to throw away' approach for a number of reasons. Management may be hostile to it in which case, they won't tell you they are using it, even if they are.
A second reason is that some developers don't see the benefit of it. You may be one of these or you may manage a team of people who think that way. All I can say is 'try it'. You may be pleasantly surprised.
A third reason is that some developers are veterans of a phenomenon that has lead to its own pithy expression. I don't think it has found its way into print yet but you will see it in the minds eye of many developers:
"Don't build a prototype. If you do, the 'suits' will likely ship it."
If it is built to be thrown away, then throw it away. Don't be tempted to ship it. If you do, your developers will never trust you again. Moreover, all the design warts that the prototype was designed to shake out, will have escaped into the wild and will come back to haunt you. It will cost you more money in the long run. Oh, and your developers will never trust you again. Repeat after me:
"We are going to throw one away."
[1]
http://www.amazon.com/exec/obidos/tg/detail/-/0201835959/104-1597283-5775944
[2] http://www.paulgraham.com/hp.html