Do Not Fool Yourself: Prototype != Production

As developers, we get attached to our work because we take pride in our accomplishments. The trouble is that we get a little too attached to progress and miss the bigger picture. We build prototypes to vet out our designs, test new technologies, and demonstrate concepts to our colleagues. But, we shouldn’t fool ourselves… prototypes are not production code.

It happens on every project. We begin building a solution to demonstrate our vision to our client / product manager / IT director / business user. But, we take a few shortcuts. Honestly, who hasn’t, right? We skip the unit tests. We may not wire it up to a production-ready data model. And, we sure don’t subject our code to the scrutiny of our peers. After all, it’s a prototype, right? We’re just trying to rally everyone around a vision! We give ourselves the standard line… “oh, I’ll refactor it and add the test cases ‘later’”.

But then “later” arrives. Now we’re invested in this prototype. After all, it is the solution that sold the business on the viability of a few new features, and… it works! Our perspective is skewed. We think… “Gee, why can’t I just start with this and build around it?” (…except that it’s not 1950 and none of us really think like Beaver Cleaver and the “gee” generation…). In any case, we become comfortable with our shortcuts, and we explain them away.

Resist the urge. Just say no. Prototype code should not be in Production.

First, if you treat your prototype as the starting point for your “real” solution, you’re starting on the wrong side of the statistics. You now have 0% code coverage on your unit tests (or maybe a meager 10-15%), which is hardly the mark of excellence on a production-ready product. Nobody wants to start work with a losing record. I encourage our teams to shoot for an ‘A’ average – 90% code coverage on all code. If 90% is good enough for our nation’s universities, then it’s good enough for me.

Next, if you use your prototype as your “real” solution, you inherit your own bad decisions. We’re geeks – educated, intellectual, creative application designers. All of us can find something we don’t like about the code we wrote last year/month/week. Why? We learned something new that improved our habits and made us better developers. Well, the same goes for an individual solution. For some reason, our ideas are always better the second time around. Most likely it’s because we subject our ideas to peer critique and we vet our code through peer reviews. Inspection begets improvement. But, it’s also (at least partially) because we felt some pain along the way as we implemented our solution – we remember the pain, and we work to overcome it the second time around.

So, do yourself a favor. Relegate your prototype code to a “Prototype” branch in Subversion and begin building production-ready code with a new folder from the trunk. Start fresh for your production application. You will thank yourself later.