For the Development Geeks

[furrbear]

From /.:
Developers:The Duct Tape Programmer

"Joel Spolsky sings the praises of The Duct Tape Programmer, who delivers programming teams from the evil of 'architecture astronauts' who might otherwise derail a project with their faddish programming craziness. The say-no-to-over-engineering attitude of the Duct Tape Programmer stems not from orneriness, but from the realization that even a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab where you're endlessly polishing the damn thing. Like Steve Jobs, Duct Tape Programmers firmly believe that Real Artists Ship."

It's a review of Coders at Work, a wonderful read that my friend Rob (cipherpunk) shared with me. If you do or have done development work, go get yourself a copy. It's a wonderful read.

Comments

[dedos.livejournal.com]

Thanks for sharing! I ordered it after checking the link from /.
I should be at my doorstep in a couple of days. :)

[furr-a-bruin.livejournal.com]

"Klingons do not "release" software. Klingon software escapes, leaving a bloody trail of design engineers and quality assurance people in its wake."

[backrubbear.livejournal.com]

I have the unfortunate honor of being in the opposite camp half the time. Crazy hacks that work that are unmaintainable. Working code that defies all other conventions in the rest of the source base. API changes that make no sense but made someone else's job easier for 10 minutes. These are the things I hate.

This is mostly because I've had the dubious honor of seeing enough of the software life cycle through from more ends than just development. Code complete on time doesn't do you any good if your code is so shaky it can't make it through QA in a reasonable amount of time. Bugs caused by sloppy architecture stymie sales when they blow up in demos. Bad code with edge conditions that manifest because someone didn't think something through enough cost time when things hit maintenance. Ugly hacks make the next round of development more expensive.

I don't expect perfect code from the people I work with. They certainly shouldn't expect it from me. But I certainly shouldn't have to look at something and wonder "what the fuck were you thinking when you wrote this".

To me, that's what I expect from a "duct tape programmer".

(Rant aside, I'll go read the article and book at a later date.)

[cipherpunk.livejournal.com]

Jeff, thank you for not leaving me all alone out here on the tree branch of having lost respect for Spolsky due to that article. :)

What Spolsky is handwaving away is that duct tape programming is a symptom of lousy software management. Take his beloved Netscape start–up days as an example. jwz has said that 80 and 100–hour weeks were not uncommon. As a software engineer, that makes me cringe. If it takes more than a sustained 40–hour level of effort, with the occasional 50–crunch, then my message for the manager is you’re doing it wrong.

I’ve worked for start–ups that have said, “well, Netscape proved it could be done, so we’re going to be the next Netscape no matter what it takes.” These have all been horrific places to work and I fled from them as soon as humanly possible. Without exception, they all went under. Management fell into the Russian Gambler’s Fallacy. When you’re playing Russian roulette, the fact the previous guy pulled the trigger five times and got the million–dollar payoff doesn’t mean that following in his footsteps is a good way to get a million dollars.

There’s a lot to be said for Steve Jobs’s maxim that, “Real Artists Ship.” I love that maxim. I tell it to everyone I know who is obsessing over the perfect to the exclusion of the good.

By comparison, industry venerates duct tape programmers for one and only one reason: because it validates management’s belief that inhumane working hours and substandard engineering processes are the normal way of business, and that with just a few more duct tape programmers they wouldn’t have to improve their software management process.

Worst software engineering article I’ve ever read, really, just awful.

… none of this is in any way a criticism of Coders at Work, though. Had Spolsky read it closely he would have discovered a great many passages which condemn the practice of duct–tape programming.

[backrubbear.livejournal.com]

There's a small addendum I'd put to my comments: Most of them apply to a company with some level of maturity. A fresh startup doesn't know enough of what it's doing most of the time to afford good engineering. Time to market is important and sometimes business overrides engineering concerns.

I think the key thing that distinguishes the *when* of such things is when a company hasn't exited the main creative phase of a new product. Freedom to tinker and to get it roughly working is very important in those early days. Getting it out the door gives the new users a chance to play with something fresh and to provide the feedback for the next cycle. To some extent, that's what agile development tries to do but such mechanisms don't work well for a market.

I also think that the kind of developers differ for such efforts. People who are good for the initial push of a startup are sometimes not good for long term sustained products. That was one thing I learned about myself: I prefer to build solid things, but I'm less good for that initial creative push - I'm more the engineer than the artist.