8 ms·

Duct Tape Considered Harmful

18 points by markdennehy 17y ago

tptacek 17y ago
I have a bad feeling that this Spolsky post --- which I liked, for what it's worth --- is going to spark a very long, very boring testing vs. shipping controversy, in which both sides, by taking sides, are going to come off grating and sanctimonius.
- wastedbrains 17y ago
  I agree and I find that the people who are architecture astronauts as he refers to them, are very vocal and active on forums, twitter, and blogging. I don't want to get into the whole testing debate, but I think you can read the whole article and remove the one point on testing and it still holds.
daleharvey 17y ago
What I took from Spolsky article wasnt that you shouldn't touch X/Y/Z, but that you should approach new code in the simplest and quickest way you can. I have often been guilty over engineering things to do them the "right way", to either end up throwing the feature out anyway or having to reengineer because I didnt know enough about the problem to fulfill its design from the outset anyway. while prototype fast is a reasonably mundane point, Its still one we get wrong time and time again, and I think programmers pay lip service to it as an ideal, but when it comes to actually having to leave that nasty bit of code alone because it does its job, too often we go down the wrong path of making it "right"
- steamer25 17y ago
  "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Knuth
aarongough 17y ago
I have a friend who develops OpenGL drivers in C for various aerospace uses and his perspective on code quality was very interesting to hear. As a web-developer I used to think of tests as frivolous wastes of time, whereas he saw them as an essential and necessary part of the development process. Since I started implementing testing on all my projects I have noticed that my ability to change the code has actually gone up, which in in stark contrast with my initial expectations. I think that having a sounds testing methodology definitely has benefits even in cases where financial/life loss due to software failure is an impossibility...
- ajross 17y ago
  But the point was that the decision interacts with the market, though. Obviously testing is good and omitting testing completely is bad. But at the end of the day the someone or something needs to pay for the software. Software vendors that ship late due to elaborate design and testing regimes get paid less, in practice, than the "duct tape" folks who beat them to market. The video drivers you mention are a good example: an aerospace customer is almost certainly operating on a slower schedule, and probably has contracted the revenue already. The value of time to market here is less. And of course the value of code quality in a vehicle safety application is much higher than it is in a consumer web app. So I'm not surprised at all that sane and smart people would make different testing decisions in the two regimes. They're both right.
  - markdennehy 17y ago
    "The market" was the motive behind the Ford Pinto memo as well, wasn't it?
    - eugenejen 17y ago
      When I was a child, my father got the Pinto. even though it is a unsafe car as we knew later. But in a then poor Taiwan, it is like a luxury and it helped him to do his job. Here is an argument against Ford Pinto case http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pinto_Case.pdf http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pint...
anonjon 17y ago
I also took the article to be about not 'over engineering' things. The phrase is 'as simply as possible, but no simpler'. If you have a simple design and a simple implementation, it will be easy to test by running it; and it will also be easy to reason about (and reasoning about your code is also a type of testing). So the point about unit testing is not that it is a bad thing, or that you should never unit test anything...merely that it is (or ideally should be) non-critical. If it is critical to your product that you unit test every little detail, you have probably taken a misstep at some point on the complexity scale. You need unit tests when the code itself is no longer a good indicator of what it is attempting to do. At that point, the code becomes meaningless and the tests begin to stand in for the meaning that the code was supposed to convey. (Essentially, you are recreating Prolog along side your Java/C/whatever, without the benefits of declarative programming and only having to write the code once). This would indicate that you are: At the wrong level of abstraction (you didn't build enough foundation for your problem). or Solving the problem in the wrong way. or Dealing with a very complex problem that you haven't adequately broken down into sub-problems. (In this case, the unit tests end up standing in for sub-problems). These are all related to not having enough state in your mind to deal with the intricacies of a problem. Many times unit-tests do help with the development end of things, but doing them all of the time seems unreasonable. I think the COM and Multi-Threading combination was mentioned as an example of wrong way or wrong level of abstraction. Pneumatic-power-nailers are nice, but many times all I need is a framing-hammer. (And in programming, sometimes you will go through with the pneumatic nailer on the first try, then realize that the framing hammer would have yielded a better solution, and re-do it with the framing hammer).
raganwald 17y ago
“Considered Harmful” Essays Considered Harmful: http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html
wglb 17y ago
Let's take a step back here. Joel's blog entry was about ONE chapter in Codes at Work. If the anti-duct bloggers were to read the entire book, they would see that TDD, C++, templates, pattern fever, OO oration, IDEs--don't get much credibility with the whole lot of them. But there are self-interest forces at work in arguing against the duct-tape arguments--advocates of patterns, tdd and so on. Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not.
- plinkplonk 17y ago
  "Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not." This is a key point. Agile methodology vendors who wax loudest about TDD and other "core practices" have never shipped any significant software [1]. None of them ever built a software product or a startup. Neither do they show us any decent body of code written with their superior approach [2] (vs talk interminable about how our code will be better if we adopt their advice and pay them the big consulting $$). After all the book is about Coders At Work, not "Methodology Vendors at Work" (which might be an interesting book, in a very horrific fashion). [1] How many of the creators of the Agile Manifesto have shipped any significant software or built a software company? Most (All?) of them are methodology consultants. [2] Kent beck has JUnit. Robert Martin has Finesse. The rest of the agile gurus don't have anything. I leave it to the readers to decide if JUnit and Finesse are significantly superior, designwise, to other Open Source code bases, written without TDD.
  - markdennehy 17y ago
    What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people have put together, systems where failures kill people, and tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system. Bugs in systems like that will kill people, and we're getting to a state these days where those systems are becoming more and more embedded in day to day life and the risk to Joe Soap is getting higher. How long until a bad UI in a GPS iPhone app turns out to be a contributing factor in a bad car accident? Or until a web-based medical app with a hidden bug screws up a dosing calculation for a patient? This whole duct-tape-it-and-ship-the-sucker mentality has got to stop, before someone gets badly hurt.
gfodor 17y ago
The amount of false dichotomies and developer stereotypes Spolsky and Atwood manage to get spewed from ordinarily calm and logical people is astounding.

18 points by markdennehy 17y ago

I have a bad feeling that this Spolsky post --- which I liked, for what it's worth --- is going to spark a very long, very boring testing vs. shipping controversy, in which both sides, by taking sides, are going to come off grating and sanctimonius.

wastedbrains 17y ago
I agree and I find that the people who are architecture astronauts as he refers to them, are very vocal and active on forums, twitter, and blogging. I don't want to get into the whole testing debate, but I think you can read the whole article and remove the one point on testing and it still holds.

daleharvey 17y ago

What I took from Spolsky article wasnt that you shouldn't touch X/Y/Z, but that you should approach new code in the simplest and quickest way you can. I have often been guilty over engineering things to do them the "right way", to either end up throwing the feature out anyway or having to reengineer because I didnt know enough about the problem to fulfill its design from the outset anyway. while prototype fast is a reasonably mundane point, Its still one we get wrong time and time again, and I think programmers pay lip service to it as an ideal, but when it comes to actually having to leave that nasty bit of code alone because it does its job, too often we go down the wrong path of making it "right"

steamer25 17y ago
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Knuth

aarongough 17y ago

I have a friend who develops OpenGL drivers in C for various aerospace uses and his perspective on code quality was very interesting to hear. As a web-developer I used to think of tests as frivolous wastes of time, whereas he saw them as an essential and necessary part of the development process. Since I started implementing testing on all my projects I have noticed that my ability to change the code has actually gone up, which in in stark contrast with my initial expectations. I think that having a sounds testing methodology definitely has benefits even in cases where financial/life loss due to software failure is an impossibility...

ajross 17y ago
But the point was that the decision interacts with the market, though. Obviously testing is good and omitting testing completely is bad. But at the end of the day the someone or something needs to pay for the software. Software vendors that ship late due to elaborate design and testing regimes get paid less, in practice, than the "duct tape" folks who beat them to market. The video drivers you mention are a good example: an aerospace customer is almost certainly operating on a slower schedule, and probably has contracted the revenue already. The value of time to market here is less. And of course the value of code quality in a vehicle safety application is much higher than it is in a consumer web app. So I'm not surprised at all that sane and smart people would make different testing decisions in the two regimes. They're both right.
- markdennehy 17y ago
  "The market" was the motive behind the Ford Pinto memo as well, wasn't it?
  - eugenejen 17y ago
    When I was a child, my father got the Pinto. even though it is a unsafe car as we knew later. But in a then poor Taiwan, it is like a luxury and it helped him to do his job. Here is an argument against Ford Pinto case http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pinto_Case.pdf http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pint...

anonjon 17y ago

I also took the article to be about not 'over engineering' things. The phrase is 'as simply as possible, but no simpler'. If you have a simple design and a simple implementation, it will be easy to test by running it; and it will also be easy to reason about (and reasoning about your code is also a type of testing). So the point about unit testing is not that it is a bad thing, or that you should never unit test anything...merely that it is (or ideally should be) non-critical. If it is critical to your product that you unit test every little detail, you have probably taken a misstep at some point on the complexity scale. You need unit tests when the code itself is no longer a good indicator of what it is attempting to do. At that point, the code becomes meaningless and the tests begin to stand in for the meaning that the code was supposed to convey. (Essentially, you are recreating Prolog along side your Java/C/whatever, without the benefits of declarative programming and only having to write the code once). This would indicate that you are: At the wrong level of abstraction (you didn't build enough foundation for your problem). or Solving the problem in the wrong way. or Dealing with a very complex problem that you haven't adequately broken down into sub-problems. (In this case, the unit tests end up standing in for sub-problems). These are all related to not having enough state in your mind to deal with the intricacies of a problem. Many times unit-tests do help with the development end of things, but doing them all of the time seems unreasonable. I think the COM and Multi-Threading combination was mentioned as an example of wrong way or wrong level of abstraction. Pneumatic-power-nailers are nice, but many times all I need is a framing-hammer. (And in programming, sometimes you will go through with the pneumatic nailer on the first try, then realize that the framing hammer would have yielded a better solution, and re-do it with the framing hammer).

raganwald 17y ago

“Considered Harmful” Essays Considered Harmful: http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html

wglb 17y ago

Let's take a step back here. Joel's blog entry was about ONE chapter in Codes at Work. If the anti-duct bloggers were to read the entire book, they would see that TDD, C++, templates, pattern fever, OO oration, IDEs--don't get much credibility with the whole lot of them. But there are self-interest forces at work in arguing against the duct-tape arguments--advocates of patterns, tdd and so on. Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not.

plinkplonk 17y ago
"Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not." This is a key point. Agile methodology vendors who wax loudest about TDD and other "core practices" have never shipped any significant software [1]. None of them ever built a software product or a startup. Neither do they show us any decent body of code written with their superior approach [2] (vs talk interminable about how our code will be better if we adopt their advice and pay them the big consulting $$). After all the book is about Coders At Work, not "Methodology Vendors at Work" (which might be an interesting book, in a very horrific fashion). [1] How many of the creators of the Agile Manifesto have shipped any significant software or built a software company? Most (All?) of them are methodology consultants. [2] Kent beck has JUnit. Robert Martin has Finesse. The rest of the agile gurus don't have anything. I leave it to the readers to decide if JUnit and Finesse are significantly superior, designwise, to other Open Source code bases, written without TDD.
- markdennehy 17y ago
  What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people have put together, systems where failures kill people, and tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system. Bugs in systems like that will kill people, and we're getting to a state these days where those systems are becoming more and more embedded in day to day life and the risk to Joe Soap is getting higher. How long until a bad UI in a GPS iPhone app turns out to be a contributing factor in a bad car accident? Or until a web-based medical app with a hidden bug screws up a dosing calculation for a patient? This whole duct-tape-it-and-ship-the-sucker mentality has got to stop, before someone gets badly hurt.

gfodor 17y ago

The amount of false dichotomies and developer stereotypes Spolsky and Atwood manage to get spewed from ordinarily calm and logical people is astounding.