The perils of keeping your prototype

20 Feb 2007

Oh sure everybody says you should throw out the prototype after you make it, but look at all that yummy code just waiting to be used. Sure you wrote it fast and without tests – but it took a lot of work and it would be silly not to just use it as the base of your real project. Brush it off, clean it up a little, and it’ll be fine.

Don’t do it.

First of all it’s not fine. Code written without the threat of production tends not to be good. But let’s pretend you did write some nice code (you didn’t but this is pretend time). Now you’ve got huge chunks of untested code floating around that looks like it does stuff but actually is just left over from the prototype. Joe dev comes along and tries to write some functionality and he comes across a bunch of prototype code. It’s really confusing. It’s doing all this stuff. Stuff that doesn’t seem to work like he thought the app was supposed to work… Huh. “Oh well, I guess that’s how they want it done so I better follow along.” he thinks. Or maybe there’s a bug and he’s looking through code to see what’s going on. It’s not a lot of fun to realize you’ve spent a few hours rummaging around dead code. Or the case of the new functionality that seems to already be done. Just a little bit of hacking and it IS done. “Except for those extra methods that I couldn’t figure out… Better just leave it ‘cause they must be important.”

It may seem silly to keep the prototype separate from the real project, especially if you’re going to be referring to it all the time. I don’t care if you do end up copying and pasting much of the prototype into the real code as you add functionality. At least this way every line you add is a conscious decision. There’s less chance of your code becoming a way confusing combination of used and unused, polished and unpolished, tested and legacy.