After reading the books Ship it! and The Pragmatic Programmer, I suggest you to read both of them, I got some proof that I am right and the fast way I sometimes like to move is not my personal bad behaviour but suggested way to develop software. Officially it is called tracer bullet development. This method suggest you to write some code to make system work for customer so they can see how the system is planned. But this is not a usual prototyping procedure but involves some real coding work too.
What is tracer bullet?
Shooting in the dark is harder than it may seem at first place because we cannot see where our bullets are going and what they hit. To get some idea where we are shooting we can use tracer bullets. These bullets draw lightning trace in the air when shot out from gun.
Photo made in first months of Winter War near Finland-Russia border. White traces in the sky are traces of tracer ammonition.
Copyright of this photo belongs to Finland Defence Forces.
Tracer bullets show only the direction, they don’t show where enemy is or where they exactly fly. Now think for a moment and read the last sentence three times more. We get only idea about direction and that’s it.
Tracer bullet development
Software development is somehow similar to shooting in the dark. The less we can communicate with customer the more probable it is for us to miss the target. There are also other dangerous factors like managers who have no software development background, unrealistic time schedules etc (read Death March about how to survive projects that are your worst nightmare). Tracer bullet development is here to help us avoid the mess.
Before coding developers discuss about interfaces that different parts of system use to communicate with each other. Of course, as a result of these discussions there will be agreement about interfaces. Now can developers write system using primitive code that is enough to let customer see it and play with it. As project goes on this demo code is replaced by real code.
It may seem like overkill, specially for large systems. But as we know already the communication errors are usually the most expensive ones in the means of time and money.
By example, to show login form to customer we don’t need real code that is covered with all kinds of tests. It is enough to use some test data and dummy objects that just demonstrate how things will work. It is easy to change and modify dummy code. The real code may need design changes in object model, changes to dependent classes and tests if something changes.
Using tracer bullet development we are able to avoid communicative misunderstandings with small costs in time and money. We can be sure that all parties of project are understanding each other and customers get the system they asked for.