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

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

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 - 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.