The Duct Tape Programmer

theodp writes "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."

Comments

my employer's fault

[rubycodez]

my employer knows I can whip out a fast 4,000 line (but ugly, no artistic talent) web portal or e-commerce app in a month when it should be a 20K line project done by a team, so that's what we do. dangerous I think, we handle real money with that shit.

False dichotomy

[ciggieposeur]

I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.

Re:Bad Mischaracterization

[khakipuce]

It's all about the people, a good developer (and a good architect) can use anything from a duct tape approach to a full-on methodology based life-cycle depending on the scale, complexity and critcality of the job in hand. You cannot use the same approach for building a sky scraper that you might use for building a garden shed.

Several issues cloud this mix:

• Non technical management really struggle to tell genuinely good developers from braggards and people who must be good because they are weird
• Architects and analysts want fashionable things on their CVs as much as developers do, so they push towards the newest buzz because their next job may depend on it

At the bottom of every successful development are a few people who just get on and write the code, it's where it actually happens. Ever see a hole in the road where one guy is down the hole with a shovel, and 4 others are stood around the top? I'm the guy down the hole, have been down coding holes for 20 years and pretty much every project I have started coding, I have finished and delivered, some where big methodology driven things, some where me against the world with a couple of weeks to deliver. But get keen interested and pragmatic people on the shovel and the job gets done

Re:True that

[plalonde2]

I'd avoid the false dichotomy.

Only unit test what needs to be unit tested. If it needs to be tested the testing will pay for itself. If it's simple enough that it doesn't need testing, then you're wasting your time writing those tests.

Half the benefit of the unit tests/test-first methodology is that they force you to design even your internal interfaces in a reliable way. The other half is knowing you didn't introduce regressions in that oh-so-clever code.

For most projects you don't need a whole lot of tests but there will be a couple of subsystems that you almost can't manage without them.

Re:True that

[mcgrew]

Software is about money guys.

Which is exactly what is wrong with software. Software should be about creating a useful tool. When you have a blacksmith who cares more about money than his craft, you have a poor blacksmith indeed. When you have a musician who cares more about money than music, he produces crap.

No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.

Architecture astronauts

[Aceticon]

I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.

The typical evolution towards wisdom in Software Engineering goes like this (simplified):

• Starting by making small programs or programs supposed to be used only once (i.e. school assignments)
• Transition 1: Discovery of code reusability, the problems with copy & paste coding and how using methods lets you partition your code into more easy to understand blocks - this is when one transitions beyond junior developer
• Transition 2: Discovery of the concept of software design and how it makes for more adaptable code which is easier to understand and how it helps main complexity small as the size of the program increases - this is when one transitions into junior designer
• Transition 3: Discover that there is such thing as too much design. That over-designing decreases maintenability, makes the code harder to understand by others and by oneself in the future. That the flexibility that the real world will require from the code will rarely match one's initial idea of what should be made flexible during design and that trying to create a top-to-bottom design that covers all eventualities actually results in an inflexible system. Above all, discovery of the value of the KISS approach: don't design/implement a specific something now because you think you will need it later, it is often easier to do it then if you do actually need it and you probably won't need it and are just making for big code instead of useful code. At the same time discover that newer isn't always better when it comes to software tools, languages and frameworks and that coolness and hype are really bad things to focus in when choosing something to use in an professional IT project - this is how you get medior designers and senior developers
• Transition 4: Discover that creating software is actually a process not an act. That a lot of things serve as feed-ins to the actual design and development of software and a lot of things feed out from it. That software isn't just made, it lives, evolves and gets changed. That making an application is easy (no mater how big and complex) and making the right application which does what's need in the right way for the users of the application is what's hard. That the quality of your feed-ins (requirements, analysis, time, people and all manner of preparations) is much more relevant to the success of a project than the code or the design. That over the long run, the true quality of the code and design is measured by how easy it is to regression test, maintain, support, extend and by how fast new designers/developers can pick up the code (which are some of the feed outs) - this is how you get senior designers and technical analysts.
• Transition 5: Discover that the applications your develop are part of an ecosystem. That software talks to software that talks to software. That many applications need to do many of the same things, only in slightly different ways. That standardizing (up to a level) things like certain kinds of exchange of information between applications or the kind of libraries used for certain common functional areas (such as multi-system logging, single-sign-on, messaging) will make for increased overall productivity and maintenability (develop and maintain a single implementation for each and distribute it as a library). Discover that standardizing on a reduced number of mature programming languages makes it easier to find people to work with them and move people around to different projects and systems - this is how you get technical architects

At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.

I would hardly call a junior designer type "architect".

Re:So, does the Duct Tape Programmer...

[Big Hairy Ian]

My experience is the Duct Tape Programmer writes the worst kind of spaghetti code in the world. The best way to deal with someone who is over engineering the system is for his project manager & team leaders to do their job and shoot him down to size!

Re:True that

[EastCoastSurfer]

Exactly. All of Joel's articles about about good to expert developers. More than likely the people he describes could use any tool or methodology and ship correct, working software.

This reminds me of when people try to copy a particular athletes workout or diet. Most professional athletes are genetic wonders and many succeed at their sport not because of their workout and diet, but in spite of it.

Re:So, does the Duct Tape Programmer...

[Lord Ender]

Are you referring to duck typing?

http://en.wikipedia.org/wiki/Duck_Type

(For the uninitiated, this is one of the reasons Ruby and Python programmers can deliver code in a tiny fraction of the time it takes Java or C# programmers.)

Re:True that - NOT

[Dare nMc]

I guess in my experience, your example doesn't really go anywhere to disprove the article. IE I had a project where we followed all the correct design principles and did 2 years of work * 5 developers for a project that was to be the future of the company. Another division had started before us a similar project with slightly different goals. The sold management on their duct tape software that met some of the spec before ours. So my project got canceled. Their duct tape software had to be completely re-written to add the remaining features (8 years later they still haven't surpassed what we had almost done.) The fact that they were done (with something) first won out. The fact that duct tape allowed them to provide the solution, and buy them the time to re-write it, in my mind showed how it makes them more successful (I did replace a bunch of their code with ours, and the correctly written code spawned other projects to use its base, so not a failure.)

So the fact that your co-worker got the jobs, seamed to show people they needed that solution, and thus seams thats the reason you got the time to re-write them. Shows that duct tape programming "works." Even if it isn't always the most efficient method in the long run. IE this is about how many projects have just been abandoned because they were stuck in doing it the right way, where you slap something together, you got your foot in the door, and may buy the time to do it the right way.

Re:True that

[mcgrew]

Indeed. I have a friend who works in construction. His boss is a stickler for quality and tries to keep costs down as well. As a result, he has more business than he can handle while his competetitors are cutting corners, charging high prices, and going out of business right and left.

Re:So, does the Duct Tape Programmer...

[Lord Ender]

To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.

Having to fuss with every little inconsequential detail has an advantage as far as testing goes, but it does come with a great cost as well. Some would argue that dynamic/duck + extra testing has the same effect with less cost than static + less testing.

Ruby and Python have only been "mainstream" for a few years, while static languages have been around since the ancient days. We have yet to see how high they can rise, but I'm betting they'll go pretty far--especially considering the fact that QA teams are far less expensive to business than programmers are.

Re:So, does the Duct Tape Programmer...

[jgrahn]

I laughed out loud when I read this. I write in C++. It's my favorite language.

Mine too, but I identify with Spolsky's duct tape programmers (not the term, but the idea).

But I can't stand these Duct Tape Programmers who are the ones casting to void * because they can't be bothered with templates.

We all set the limit somewhere ... Spolsky, JWZ, ESR and a whole lot of slashdotters think C++ is on the wrong side of that limit. I like to think they're basing that on old information, from the hype days in the 1990s when everyone had to pretend that they were developing abstract general reusable libraries rather than Getting Work Done. I think that sick attitude is mostly gone from C++ today (although some (not all) Boost libraries give me nasty flashbacks ...)

Now I know nothing of COM or CORBA

That is something to be grateful for,

but multithreading is generally not something you have a choice about. Avoid it if you can, think very carefully about when you need to use it because of the application requirements.

Sure you have a choice. You can pick a task which has no need whatsoever for multithreading, and add threads. Lots of people do this, when a sane select() loop would have been enough.

Re:Since when did quality become optional?

[dominator]

Good enough means good enough. It's not 50%. It's not 80%. It's whatever is the powers that be decide is the appropriate trade-off between competing interests (i.e. time to market, cost of deployment, $ paid to developers, estimates of the cost of future bug fixes, ...). If the market doesn't accept the product, it only means that their definition of "good enough" was wrong, not that there isn't a different "good enough" that the market will embrace.

"Good enough" for the software that runs a nuclear reactor or the space shuttle is probably near 100%. Pace-makers, surgeries, and pharmaceuticals failing? It's been known to happen. Sure, maybe only in 1/10000 cases, and only if you don't have a pre-existing condition. So, good enough is maybe five nines there. "Good enough" for that $1 umbrella you bought at Wal-Mart probably means something entirely different.

Re:So, does the Duct Tape Programmer...

[MagikSlinger]

To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.

Um... no. I work with a proprietary duck type language and Java at work. Java does not catch non-errors, IMHO. On the other hand, we have to test the hell out of the duck type language because we can only find the bugs at run-time, and with the complex code we write at work, that takes a LONG time!

Duck typing is nice and has some nice features. I think it makes remoting such a painless thing to implement. But in practice, I do not find it is better or faster than statically typed languages. In fact, if you are working in a large team, static typing is faster because if goober over there on the other side of the floor changes his interface, he is the one who notices it and has to fix it. In the duck-type language mentioned above, I find out about it when the next nightly dev build happens and I spent half the morning fixing problems he caused.

Duck typing is simply different. It has certain strengths in certain situations, just as statically typed languages. I know this in an unpopular view but: the right language for the right task. Seriously, just because Python/Perl/Ruby is your Dremel motor tool doesn't mean you should remodel your kitchen and build your own cabinets from scratch with just a Dremel!