Develop Everything the Second Time First

an Extreme Maverick Approach

by Geoffrey Slinker
v1.1 DRAFT March 2006
v1.0 DRAFT October 2004

Abstract

Applying the Maverick approach using the Extreme premise that if something is good then we will do it all the time or do it to the extreme the idea of developing a software product the second time first came to mind.
If a piece of software is always better the second time we develop it then we will always develop the software the second time.

Introduction

After studying the Extreme Programming methodology it inspired me to consider other things that can be taken to the extreme. Being a Maverick follower I said to my self, "Self, why aren't other good practices of development taken to the extreme?"
I have been a student of product estimations for many years. It seems commonly accepted that when estimating the cost and time of a project you must have prior experience that is directly applicable to the new task. Otherwise estimations can be off 300% in either direction.
After writing a new product if the development team was asked how long it would take to develop the product they just developed then they would be able to give you a very accurate estimate that excluded the mistakes of the original effort. Often I have heard, "If there was just time to write this code over again I could do it right." Right means a lot of things here but I feel it boils down to the fact that right means that the correct domain model has finally been recognized and it would be great if the team was allowed to refactor or re-implement the product.
So, if writing things the second time produce products that are truly superior than the original then the first thing we should do is write the product the second time!

Second Time all the Time

Since coding a project the second time can give great improvements in performance, coupling, cohesion, and overall domain model then why don't departments just plan on re-writing the product and only ship the second release? Because that sounds expensive. That sounds as if better planning had occurred we wouldn't want to re-write the system. That sounds as if we had hired better people they could have done it right the first time. That sounds like something went terribly wrong.
The truth is that it could be a sign of all of the things above and it could also be a sign of a product that had a scope that was not definable until some experiments had occurred.
Prototyping is the essence of this idea. I am not saying this is a new idea! But prototyping sounded expensive and since the company always wanted to ship the prototype rapid prototyping emerged. The term rapid was used to discourage the company from wanting to ship the prototype. Because of this desire to ship prototypes and the understanding from the development that prototypes were very useful the development team had to undermine the quality of the prototype (at least by name and often by quality) to keep the company from shipping the prototype.
In the past few years other terms have arisen that refer to the idea of writing something first so that the second version can be developed. Terms such as a "one off", "a thin thread", and "a spike". These obvious prototypes or experiments are tools that are commonly used. There names may exist to avoid the conversations with management to justify prototypes.

Unit Testing is Prototyping

As I considered the fact that development continued to prototype and experiment during software development I thought about how unit testing plays a role.
I propose this description of unit testing:
Unit testing is prototyping the interface and any stubbed or mocked components necessary to define the expected behavior. The unit tests are refactored until the desired behavior is represented and the interface is correct for the domain. Then you write code to get the tests to succeed.
Isn't that a form of prototyping? Isn't it a way of writing things the second time? Isn't that what Test-First-Design is all about? You are coding up the interfaces before they are implemented. You are thinking about those interfaces and changing them to meet the idea of a fluid design. You are running scenarios through your mind anticipating issues. Mocked objects maybe considered oversimplified prototypes. Stubbed methods are definitely simplified to the extreme.

The Future of Prototyping

The benefits of writing something first as an experiment and then writing it a second time for production have been known for many years. How can these benefits be used more efficiently? Ignoring the various names of current activities that are centered on the old term prototyping there should be more use of these activities without the fear of shipping the prototype. Maverick development is concerned with trust. Trust your engineers to know that a prototype, experiment, or spike is necessary and trust them to take the lessons learned and apply those to a truly production quality resultant.

Conclusion

If allowed to re-write a piece of software it is generally accepted that the second version is superior to the first in a myriad of ways.
Since writing software the second time is better, we will write the software the second time at first.
Prototypes, rapid-prototypes, one-offs, thin threads, experiments, spikes, and unit tests are all methods that address the idea of writing things the second time give better results.