in reply to OpEd: Programming is not Team Sports

From Calvin and Hobbes:

CALVIN: How do they know the load limit on bridges, Dad?
DAD: They drive bigger and bigger trucks over the bridge until it breaks. Then they weigh the last truck and rebuild the bridge.

For what it's worth, I have built a (small) house in the "release early and often" sort of fashion, without any blueprint beyond some rough outlines on paper. Obviously there are disadvantages: sooner or later you'll realize you forgot to leave room for such-and-such, and have to adjust or redo something to compensate. You could end up spending a day breaking up concrete with a jackhammer because you forgot to put in the drain for your shower.

But there are advantages too. It's hard to know just what a room or an overhang is going to look like until you see it for real; blueprint drawings or even CAD mockups just aren't the same. If you're figuring it out as you go along -- and building with that in mind -- it can be easier to change your mind and make adjustments along the way when you have new or different ideas. You're not constrained to a blueprint because you don't have one.

There has to be a healthy balance, of course, between rigid pre-planning and unplanned chaos. But when it comes to software, I think there are valid reasons to lean more toward the chaotic end. It's a lot easier and cheaper to tear down a program and start over than it is to tear down a house and start over. And release-early-and-often gives you much faster feedback than you can get by doing your own testing. (How many times have you found a bug in a piece of commercial software and thought, "How could they possibly miss that?" That was a regular thing in C64 games back in the 80s, even from software houses with large teams of testers.) Faster release cycles mean faster development.

The other reason I tend to lean toward try-and-fix is that it's just not possible to plan perfectly. No matter how many planning meetings you have, how much documentation you write up in advance, how many tests you prepare, something is going to go wrong and have to be fixed. So no matter how much you plan, you still need the flexibility to respond to issues that come up. If you have that flexibility, why not use it as much as possible?

Aaron B.
Available for small or large Perl jobs; see my home node.

  • Comment on Re: OpEd: Programming is not Team Sports

Replies are listed 'Best First'.
Re^2: OpEd: Programming is not Team Sports
by Anonymous Monk on May 26, 2012 at 07:24 UTC

    It's a lot easier and cheaper to tear down a program and start over than it is to tear down a house and start over.

    That is why all the real geniuses design their house on paper, then build a paper house (or bamboo and tarp) and live in it for a while (or do some walkthroughs)