3 ms·

Why Joel Spolsky was wrong about 'duct tape programmers' being good programmers.

23 points by markdennehy 17y ago

zavulon 17y ago
This post reminded me of "Moby Dick". Extremely long introduction that has nothing to do with topic promised in the title, so boring that I lost all interest, before getting to the author's actual point.
maxcap 17y ago
I skipped the first 3/4 to get to the point. Though I think there are enough people that don't know the history to justify that first 3/4.
raganwald 17y ago
So I see that the OP's title is "Duct tape considered harmful" but the title here is "Why Joel Spolsky was wrong about 'duct tape programmers' being good programmers." These are two very different propositions. The OP's title suggests that duct tape is a bad idea and when you read the post you discover the essay was prompted by Spolsky's post. Whereas the title here suggests that the focus of the article is Joel Spolsky. In fact, the if the article is really about why Spolsky was wrong, this admits the possibility that Duct Tape programming is helpful, but that Spolsky got the arguments in its favour wrong. I'm not arguing the editorialized title is a poor choice, just pointing out that it has a very different and much more personal focus than the OP's title. What do people think: Is it an improvement on the original?
weichi 17y ago
I don't really get this article. Dennehy writes: However, while Dyer was making a point based on insufficient reliability and robustness in the available tools, Spolsky is making the same assertion purely on the basis that it takes more time to produce a good design than to use a simpler tool and “duct tape” a solution. This is not an accurate reflection of Spolsky's article. In particular there is this paragraph: One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain. Added: Spolsky is not claiming that these techniques take too much time. He is claiming that it is very hard to use these techniques to make a product that is reliable and robust. My reading of Spolsky is that he is making the claim that is it a good idea to have programmers on your team who are very focussed on shipping product, and don't really care whether the technology being used is particularly advanced or popular. They just want to do whatever it takes to ship. I think he's right; it's good to have these people around. Programmers love learning about new technologies and programming techniques, and when we learn about them we want to apply them. Our enthusiasm can push us to use technology that isn't really required for the problem at hand, and when that technology is difficult to use correctly, this can cause big problems. Having someone around keep you focussed on what matters - shipping a working product - is very helpful.
MartinCron 17y ago
The notion that there's only one kind of "good" programmer strikes me as very shallow. The way that everyone's vision of good programmer seems to align with "just like me" is egotistical as well. Is there just one kind of good writer? One kind of good chef? One kind of good lover? Sure, there are some traits that generally correlate with good programmers (clear thinking, love of scientific method, intellectual honesty) and some traits that generally correlate with bad programmers (magical thinking, forgetfulness) but after working with many, many different kinds of programmers, I've found that there's more than one way that works and having different kinds of people on your team is a good thing. Monoculture leads to groupthink and groupthink is an innovation killer. I like to think that I'm a good programmer (not great like some people I know, but whatever). I'm good at the kind of work that I choose to do, but I'm aware that there are all sorts of scenarios that I'm not right for. I once left a job after just a few months because the technology/team/culture fit just wasn't right; to that group, I surely wasn't a good programmer.
anonjon 17y ago
I think that this largely misses the point. The first thing to point out is that writing software doesn't map very well onto civil engineering. In civil, your base requirements are supposed to be very well defined. 'I need a bridge from point a to point b, it has to support x amount of traffic weighing y kilos'. The point of the Tacoma Narrows incident is that 'flutter' was something that was hereto unmentioned in the design requirements of the bridge. It wasn't accounted for, therefore the bridge collapsed. To imply that 'proper engineering' would have prevented the collapse is wrong. They used proper engineering... they just didn't account for everything that they needed to account for. No one is going to argue that solid design, trusted components, testing and QA are not important parts of programming. (They are good, especially the components, testing, and QA bits). What the original Spolsky 'duct tape programmer' post is railing against is the disguise of over-engineering (because of incompetence) as the above things (particularly the design part). The point being that the extremely competent don't need to disguise their software in an elaborate drapery of buzzwords and patterns. (Because they don't need a justification to fall back on if it doesnt... 'well we used x and y and z hot new thing').
- potatolicious 17y ago
  I majored in a traditional engineering, and I wish programmers/CS types would stop comparing programming with mechanical/civil engineering; they are completely different processes with completely different mentalities due to completely different requirements. Which is not to say there isn't some overlap - writing software for, say, a MRI machine would likely be held to the same processes and standards as most traditional engineering, but let's be honest, 99% of programming isn't that. > "The standard approach taken to minimise or prevent these unacceptable outcomes is conservative design, using trusted components, with testing and quality assurance being critical parts of the design and implementation processes." I think the blog author is out of his expertise here - this is an extremely "software" abstraction of the engineering design process. I'm not convinced the traditional engineering process works at all in software - traditional engineering is waterfall (where do you think it came from?), but unlike a bridge you rarely ever know all of your requirements and specifications up front. Also, you design 100% of a bridge up-front because you can't "iterate" a bridge, but you sure as hell can iterate a website. We push code out quickly and iterate because we can, and the consequences for system failure are minimal at best. Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. This is why I balk every time someone thinks we should be held to the same standards as traditional engineers - there's no compelling gain and everything to lose.
nickelplate 17y ago
I am not Joel's biggest fan, but sometimes I feel that his detractors choose not to put his writing in context and only criticize him to create link bait. Joel was writing about an interview of Jamie Zawinski. Joel and jwz are of the same generation. jwz worked at Netscape in the early 90s. In the early 90s, C++, templates, multiple inheritance and multithreading did not work. Dennehy also somehow seems to miss Joel's main point that programmers should be pragmatic and be wary of using technologies they don't understand, as this is bound to get in the way of shipping a product.
bigtech 17y ago
The article concludes with the summary 'duct-taping a solution can be harmful'. Would anyone, include Joel dispute such an obvious point?
Tichy 17y ago
Summary: blog author disagrees with Spolsky, but doesn't really provide any arguments. Pointing to the Tacoma bridge seems a bit silly. I suspect the Tacoma bridge incident is more like the unpredictable black swan, so more meticulous engineering would not have prevented it either.
GFischer 17y ago
Yet I think that Joel nailed it with this phrase: "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" I also agree with nickelplate's comment (summary: Joel's main point that programmers should be pragmatic and be wary of using technologies they don't understand, as this is bound to get in the way of shipping a product.)

23 points by markdennehy 17y ago

This post reminded me of "Moby Dick". Extremely long introduction that has nothing to do with topic promised in the title, so boring that I lost all interest, before getting to the author's actual point.

maxcap 17y ago

I skipped the first 3/4 to get to the point. Though I think there are enough people that don't know the history to justify that first 3/4.

raganwald 17y ago

So I see that the OP's title is "Duct tape considered harmful" but the title here is "Why Joel Spolsky was wrong about 'duct tape programmers' being good programmers." These are two very different propositions. The OP's title suggests that duct tape is a bad idea and when you read the post you discover the essay was prompted by Spolsky's post. Whereas the title here suggests that the focus of the article is Joel Spolsky. In fact, the if the article is really about why Spolsky was wrong, this admits the possibility that Duct Tape programming is helpful, but that Spolsky got the arguments in its favour wrong. I'm not arguing the editorialized title is a poor choice, just pointing out that it has a very different and much more personal focus than the OP's title. What do people think: Is it an improvement on the original?

weichi 17y ago

I don't really get this article. Dennehy writes: However, while Dyer was making a point based on insufficient reliability and robustness in the available tools, Spolsky is making the same assertion purely on the basis that it takes more time to produce a good design than to use a simpler tool and “duct tape” a solution. This is not an accurate reflection of Spolsky's article. In particular there is this paragraph: One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain. Added: Spolsky is not claiming that these techniques take too much time. He is claiming that it is very hard to use these techniques to make a product that is reliable and robust. My reading of Spolsky is that he is making the claim that is it a good idea to have programmers on your team who are very focussed on shipping product, and don't really care whether the technology being used is particularly advanced or popular. They just want to do whatever it takes to ship. I think he's right; it's good to have these people around. Programmers love learning about new technologies and programming techniques, and when we learn about them we want to apply them. Our enthusiasm can push us to use technology that isn't really required for the problem at hand, and when that technology is difficult to use correctly, this can cause big problems. Having someone around keep you focussed on what matters - shipping a working product - is very helpful.

MartinCron 17y ago

The notion that there's only one kind of "good" programmer strikes me as very shallow. The way that everyone's vision of good programmer seems to align with "just like me" is egotistical as well. Is there just one kind of good writer? One kind of good chef? One kind of good lover? Sure, there are some traits that generally correlate with good programmers (clear thinking, love of scientific method, intellectual honesty) and some traits that generally correlate with bad programmers (magical thinking, forgetfulness) but after working with many, many different kinds of programmers, I've found that there's more than one way that works and having different kinds of people on your team is a good thing. Monoculture leads to groupthink and groupthink is an innovation killer. I like to think that I'm a good programmer (not great like some people I know, but whatever). I'm good at the kind of work that I choose to do, but I'm aware that there are all sorts of scenarios that I'm not right for. I once left a job after just a few months because the technology/team/culture fit just wasn't right; to that group, I surely wasn't a good programmer.

anonjon 17y ago

I think that this largely misses the point. The first thing to point out is that writing software doesn't map very well onto civil engineering. In civil, your base requirements are supposed to be very well defined. 'I need a bridge from point a to point b, it has to support x amount of traffic weighing y kilos'. The point of the Tacoma Narrows incident is that 'flutter' was something that was hereto unmentioned in the design requirements of the bridge. It wasn't accounted for, therefore the bridge collapsed. To imply that 'proper engineering' would have prevented the collapse is wrong. They used proper engineering... they just didn't account for everything that they needed to account for. No one is going to argue that solid design, trusted components, testing and QA are not important parts of programming. (They are good, especially the components, testing, and QA bits). What the original Spolsky 'duct tape programmer' post is railing against is the disguise of over-engineering (because of incompetence) as the above things (particularly the design part). The point being that the extremely competent don't need to disguise their software in an elaborate drapery of buzzwords and patterns. (Because they don't need a justification to fall back on if it doesnt... 'well we used x and y and z hot new thing').

potatolicious 17y ago
I majored in a traditional engineering, and I wish programmers/CS types would stop comparing programming with mechanical/civil engineering; they are completely different processes with completely different mentalities due to completely different requirements. Which is not to say there isn't some overlap - writing software for, say, a MRI machine would likely be held to the same processes and standards as most traditional engineering, but let's be honest, 99% of programming isn't that. > "The standard approach taken to minimise or prevent these unacceptable outcomes is conservative design, using trusted components, with testing and quality assurance being critical parts of the design and implementation processes." I think the blog author is out of his expertise here - this is an extremely "software" abstraction of the engineering design process. I'm not convinced the traditional engineering process works at all in software - traditional engineering is waterfall (where do you think it came from?), but unlike a bridge you rarely ever know all of your requirements and specifications up front. Also, you design 100% of a bridge up-front because you can't "iterate" a bridge, but you sure as hell can iterate a website. We push code out quickly and iterate because we can, and the consequences for system failure are minimal at best. Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. This is why I balk every time someone thinks we should be held to the same standards as traditional engineers - there's no compelling gain and everything to lose.

nickelplate 17y ago

I am not Joel's biggest fan, but sometimes I feel that his detractors choose not to put his writing in context and only criticize him to create link bait. Joel was writing about an interview of Jamie Zawinski. Joel and jwz are of the same generation. jwz worked at Netscape in the early 90s. In the early 90s, C++, templates, multiple inheritance and multithreading did not work. Dennehy also somehow seems to miss Joel's main point that programmers should be pragmatic and be wary of using technologies they don't understand, as this is bound to get in the way of shipping a product.

bigtech 17y ago

The article concludes with the summary 'duct-taping a solution can be harmful'. Would anyone, include Joel dispute such an obvious point?

Tichy 17y ago

Summary: blog author disagrees with Spolsky, but doesn't really provide any arguments. Pointing to the Tacoma bridge seems a bit silly. I suspect the Tacoma bridge incident is more like the unpredictable black swan, so more meticulous engineering would not have prevented it either.

GFischer 17y ago

Yet I think that Joel nailed it with this phrase: "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" I also agree with nickelplate's comment (summary: Joel's main point that programmers should be pragmatic and be wary of using technologies they don't understand, as this is bound to get in the way of shipping a product.)