The perils of keeping your prototype

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.

Comments

Vivek Haridas said…
I am not sure if TDD during protyping is actually an over kill. I have seen it saving time, giving direction and helps in having a good development pace even for prototyping.

Though, I am not sure about using mocks during that stage as maintaining them can be a speed breaker when interactions between objects are still being conceptualized.

Further, even if one decides to keep the prototype without tests,
the tools producing test coverage metrics employed in the build process of the production code should throw light on untested code giving an opportunity to improve on it.
February 19, 2007 at 11:24 PM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more