12 ms·

The Duct Tape Programmer (Response from Uncle Bob Martin)

118 points by johns 17y ago

itistoday 17y ago
If you're wondering whether either party in this discussion has any new insights or ideas to share that you haven't heard of before, do yourself a favor and completely ignore all of this masturbation. Here, I'll summarize the conversation: "Quit dicking around and ship!" "Sure, but you don't want me to ship shit!" "C++ sucks!" "C++ sucks, but sometimes it's a necessary evil!" There, saved you an hour.
tristan_juricek 17y ago
The same feeling hit me when reading this: the spirit of the oringal "Duct Tape" blog was right, but the specifics kind of overgeneralized. What I took away: most programmers don't have a sense of perspective on the products they're building - to most of us, it's more software then product. My nutshell analogy in Joel-speak: "software perspective is to architecture astronaut as product perspective is to duct tape programmer". The dangerous path you get on is "always shipping" without paying attention to what maintenance means. Of course, this only matters to a Real Business - you know, places that make money instead of burning it. But I find that there is a breaking point where all that code rushed out of the door starts to cost ya. And yeah, you might have to consider a revision, perhaps even adding fancy things like unit tests to figure out what the hell is breaking, or a template to reduce the code base size, whatever. But even in maintenance mode, the perspective still doesn't change. It should be about making a good product (lowering maintenance costs to speed up new development) instead of "the right way to build software".
- dasil003 17y ago
  Yeah, Joel is definitely, definitely wrong about unit tests. Not in the TDD/BDD/Agile koolaid kind of way, but in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity. the dangerous path you get on is "always shipping" without paying attention to what maintenance means The Joel article glosses over this too much. Why? Because this is what the unwashed masses of programmer wannabes attempt to do all day every day. You know these people, the ones that just have no business being programmers. In other industries there are standards, credentials and transparent performance evaluations that prevent people like this from even getting hired. Yet in the programming industry they make up a disturbing percentage of the work force. That's one extreme--the most common one. Joel is more focused on the architecture astronauts who need code to be a little too elegant. I know first hand that these kinds of people can really damage your ability to ship a product if given too much control, but I think it's wrong to draw a distinction and favor a "duct-tape programmer". First, because most of these people probably have the capacity to ship amazing stuff with a little guidance and the occasional reality check from more "duct-tapey" colleagues. Second, because these guys push forward the state of the art. They often see the big architecture picture in a way that others don't. They may waste a lot of time by short-term metrics, but their work is the only kind that eventually leads to long-term dividends. Occasionally some of them may be so obsessive compulsive that they just can't be forced to ship. Fine, they should go get Ph.Ds and do great things in academia, but they're still infinitely more valuable than the people who don't even really grok programming.
  - holygoat 17y ago
    "in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity." His whole point is that short-term productivity is sometimes more important. No point building a product that'll be easy for you to extend in the future if you don't build it quick enough to have a future.
    - dasil003 17y ago
      My whole point is that short-term productivity doesn't need an advocate. If you're literally going to die then sure, go ahead and throw the hail mary. However in the vast majority of cases the future becomes the present quicker than anyone foresaw and then you find out that 20% time savings has now put you in a position where all future development is 50% more expensive, at which point you either (possibly) scored an amazing victory or you (more likely) handed yourself a crippling setback. You know, sort of like the situation that presumably led to the rewrite of Mozilla.
      - The_Lost_Hacker 17y ago
        However in the vast majority of cases Sorry, but that is extremely wrong. In the vast majority of cases, every bit of work you did amounts to nothing. For every successful startup, there are thousands of failures. There is absolutely no point in wasting time on ANYTHING long term until you are sure of success, whether that be attracting a shitload of users or making a shitload of money. I learned this lesson in an extremely painful way.
- j_baker 17y ago
  Personally, I think the key is in understanding that hacks are fine as long as they're localized. Generally, it's ok to fudge in places. But hacks shouldn't compromise the "big picture".
  - dkarl 17y ago
    hacks are fine as long as they're localized That's the difference between a duct tape programmer and a genius duct tape programmer. The genius has a huge brain that envelopes the entire program. To the genius, everything is local. The non-genius duct tape programmer can't comprehend the entire program, so he just blindly hacks on local problems. When you can't comprehend the whole system at once, you have to use abstraction and good design to ensure that your locally good parts will interact to create a good whole. Compare this quote from Charles Simonyi: Right now, I have to really concentrate and I might even get a headache just trying to imagine something clearly and distinctly with twenty or thirty components. When I was young, I could imagine a castle with twenty rooms with each room having ten different objects in it. I would have no problem. I can't do that anymore. Now I think more in terms of earlier experiences. I see a network of inchoate clouds, instead of the picture-postcard clearness. But I do write better programs.
    - j_baker 17y ago
      To take this to an even more absurd level, a true genius duct tape programmer is one who knows that the rest of his team aren't geniuses and programs as such. :-)
- sayrer 17y ago
  didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?
  - plinkplonk 17y ago
    "didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?" In those days, almost everyone writing desktop softare got their butt kicked my programmers writing multi threaded COM who worked at Microsoft, a company that indulged in blatantly illegal or semi legal tactics to do said "butt kicking". Eric Sink recalls how he had an epihpany when he came to know that Micrsoft had 1000 developers working on IE, a product that they gave away. I wouldn't judge programming ability by getting steamrollered by the MS juggernaut.
    - DrJokepu 17y ago
      By giving away Internet Explorer free, Microsoft made web browsers a commodity. Before that, commercial users had to buy licences for Netscape Navigator. I think the web greatly benefited from that move.
mikedouglas 17y ago
Uncle Bob seems to be confusing spirit with conclusion. JWZ and Joel are arguing against "[using complex technologies] for their benefits", where simpler tech would suffice. When you're designing a browser, C++ and multithreading do have benefits, but "Duct Tape Programmers" would argue that they aren't worth the design overhead when you're facing a tight deadline. Same with COM, unit tests, design patterns, etc. Obviously, Joel doesn't believe these have no benefits and that they're only used because they're cool. He doesn't endorse them because he doesn't believe they are worth it. It's fine if you disagree with the duct tape mindset, but don't construct strawmen to show "we all really agree".
- branden 17y ago
  I think the problem with Joel's post is that you have to read between the lines to understand what he's advocating. He knows that a strong voice makes for a more compelling blog, but that caused his message of balance and tradeoffs to get muddled. As a programmer who can engineer to a fault, I found Uncle Bob's post much more useful.
  - mikedouglas 17y ago
    I'm not sure. Uncle Bob's post came off as so reasonable and moderate that I have trouble applying it to any practical situation. Joel's post drew conclusions I don't agree with (redesigning to add multithreading after the first release seems like classic 'second system syndrome'), but at least I had a fairly good idea of the personality he was describing.
- psyklic 17y ago
  I believe that Joel knows that "C++ and multithreading do have benefits" -- the problem is that most people do not know how to properly code C++ and multithreading. So, even if you do use them appropriately, someone will edit the code at some point and not quite understand how to use them correctly.
andreyf 17y ago
As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up. This seems logically impossible. Maybe I'm misunderstanding TDD, but at the heart of it, TDD seems to suggest you: 1) Give instructions that describe how to check the instructions you're about to give are correct 2) Give instructions This is not the right solution to the problem "I'm unable to give the computer the instructions I intend". At the very fundamental level, it clashes with DRY, and is only effective if you're very uncertain in your ability to do (2). The right solution is improving your ability to do (2) - by creating better abstractions and metaphors, not by repeating yourself.
- pseale 17y ago
  One of the things I like about the TDD experience is it assumes you're not a 'strong enough programmer' and works with your failings. If you're the perfect OO programmer who has memorized all APIs, TDD is worthless, because you can just bang out code the first time correctly. If you write perfect code, why bother exercising your code first in tests when you write it correctly the first time, every time? For me, it helps. I'm going to go out on a limb and say it will help you too. If you haven't tried TDD, I'd recommend attempting it at least once, maybe try running through a simple problem with a partner or at a coding dojo.
- plinkplonk 17y ago
  "As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up." One assertion counters another. Joel is wrong because "Uncle" Bob says so. Why do TDD zealots sound like religious preachers? No harm writing unit tests. They serve well for (a certain amount of) regression testing. The whole Test Driven approach to designing software is more dubious (but wildly endorsed by the Agile consultant crowd). More sober developers seem to disagree. From Coders at Work "Seibel: What about the idea of using tests to drive design? Norvig: I see tests more as a way of correcting errors rather than as a way of design. This extreme approach of saying, “Well, the first thing you do is write a test that says I get the right answer at the end,” and then you run it and see that it fails, and then you say, “What do I need next?”—that doesn’t seem like the right way to design something to me."
astine 17y ago
It's better to ship shit than not at all, but it's better to ship late than to ship shit. The problem is that if you ship too late, you don't ship at all.
- j_baker 17y ago
  As much as I hate to quote the zen of python: Now is better than never. Although never is often better than right now.
- rm-rf 17y ago
  I've been on the 'shipped shit' side of applications a couple times. Ten's of thousands of customers and a shiny new app that could only be described as shit. I'd have rather had the product late.
  - holygoat 17y ago
    But would the customer?
wglb 17y ago
Well, perhaps uncle Bob should read not only Joel's column but also Peter's book. JWZ is not alone in that book (Coders at Work) about not using fancy stuff. C++ gets a pretty universal smackdown from all there. In fact, one of the hackers there preferentially codes in assembly, because C is not close enough to the machine. There are many nuggets there about IDE, unit testing, proof of program correctness, literate programming, design patterns. My reading of the book is that if your gig is agile or TDD or templates, you will have a cold audience in those coders. Even if you bring it on with attitude.
- coliveira 17y ago
  JWZ says that one of his methods to smell bad developers is finding if they are too excited about C++ and templates.
ilyak 17y ago
Joel's point wasn't that some programmers aren't smart enough to use C++ plus COM plus multithreading. He just said that humans aren't smart enough. They, however, might think that they are. Which is sad.
davidmabe 17y ago
In Joel Spolsky’s recent blog he talks about "Duct Tape Programmers". I'm not sure I trust anyone that doesn't know the difference between a "blog" and a "post".
simplegeek 17y ago
I don't use Visual Studio for work but I've used it for some side projects. What's wrong with that? Not sure why author doesn't like it. Agree with rest of the article though, to extent.
- middus 17y ago
  He seems to be more of a UNIX kind of guy.
ardit33 17y ago
"As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up. One day I hope Joel eventually realizes this. " Bullshit. I call TDD more like "insecurity driven development". Perfect fit for big corps, where mistakes are punished, and being fast is not really rewarded. *hence the myriad of processes to do even simple check-ins. There is much better ways to deal with it: 1. Design interfaces, that implement the features you think you need. That's like the outline of your essay. 2. Have classes that implement them (put all messy code there). Write your essay. 3. Do some functionality testing on the features that are important, and can reasonable be measured (.ie. no functionality testing/unit testing in UI stuff). And make sure you use it. Unit test may catch only some stuff. Proof read it. From my experience in my previous startups, If you have to ship in three weeks, unit testing is the very first thing that gets tossed out of the window. At the end of the day, who cares if your product has few bugs. You got to ship something. And I am saying this from experience, where a product I worked is being used by over 2million of people. Buggy? Oh yes. Did the bugs kill the overrall experience, i don't think so. If we had missed that deadline, there was huge financial ramification for the company (apart 10s millions of dollars, it was a relationship breaker with the main client). We took our time to fix some of those bugs on subsequent releases. If we had to do TDD, we probably would have never get done in time. Sure we might have found and fixed some of the bug earlier, but none of those bugs were detriment to the whole experience anyways. The only time you really should care to test about even the most minuscule feature, is if you are doing some highly financial/sensitive stuff. Most starts are not in that field anyways.
- johnb 17y ago
  "insecurity driven development" is probably a good alternate title for TDD, but instead of taking it at it's trollish face value it can generate a good analogy. If you start walking down a dark alley - you start feeling insecure. You've got a few options from that point. You can back out of the alley and hey, no more insecurity. A little embarrassing but you're feeling OK, you just have to go the long way round the block. You can push on through the alley in the dark - something bad could happen or you could get through fine. You don't really know until you've popped out the other side. Or you could carry a god-damned torch. Obviously when carrying a torch, you don't have it turned on all the time, just when you wander into darker areas where you're less sure of the environment. It lets you walk at full pace without stubbing your toe or getting mugged or whatever. In more concrete terms: I'm a bit of a poor-weather TDDer (same with pair programming) If i start working on something that could be algorithmically challenging, cuts across multiple layers of our app, touches something scary (like our accounting code, because i don't want to lose any of our $$$), or am just plain stumped - I write a test. It fails. I make it pass. I write the next. I make it pass. I realise my code looks like ass, I refactor. The tests still pass. I can give an actual example from this week. Our app is a large RoR app that serves multiple sites from the one codebase based on an internal DSL we have. We're in the final week of a must launch redesign (date was set because of a bunch of marketing, etc) and I get an urgent and large last minute change dropped on my desk (i'm sure you all know that feeling). I'll admit my first move wasn't to go TDD, I just went for the quick and hopeful move of quickly adding some code that looks like it should work to our DSL. It didn't. So my very next move, knowing that I have a deadline I must hit with a risky technical change, was to start writing tests. If i hadn't, I'd have to be verifying my code works by checking around 3 different pages after a server restart which is both slow and 4 layers away from the changes. So it was faster in real time. I'm not a big fan of TDD zealots, TDD is just another tool in the box. But TDD haters really get my goat. You're willfully shutting yourself out of a tool that can make your life easier, and help deliver code faster.
sutro 17y ago
Look at the surrounding website. What is being sold by Object Mentor? Training, consulting, books, advice. Not software.
- jister 17y ago
  True. That is why they boast on their TDD advice all the time...that developers should TDD this and that. And what happens if the project failed? Ah, the developers didn't implement TDD correctly. Period. TDD != Software
- bkovitz 17y ago
  How could anyone upmod that? It's pure ad hominem.
  - holygoat 17y ago
    No it's not. It's an instance of "cui bono", and skepticism about credentials.
    - deleted 17y ago
      [deleted]
    - bkovitz 17y ago
      How is it not ad hominem? It's telling facts about the speaker to put down the content. Regarding credentials, we are judging the content on its merits, not deferring to Uncle Bob's authority.
    - thrdOriginal 17y ago
      The comment can be read as "you're just saying that because you sell training, consulting, books, and advice, not software." Which absolutely has nothing constructive or destructive to say about the merits of Uncle Bob's argument. Looks like an ad hominem to me.
  - tigerthink 17y ago
    Let's say we are arguing about the color of Mount Everest. Joe says it's blue and Mike says it's white. Would it be relevant to the debate if Joe had never in fact seen Mount Everest? In the same way, software advice that doesn't take the form of deductive argument from mutually agreed-upon principles is largely valuable insofar as the person peddling it is experienced and honest.
lacker 17y ago
Unit testing (done TDD style) does not slow you down, it speeds you up. I do a lot of unit testing myself, but I know many programmers for whom unit testing does slow them down. Some people get so caught up in unit testing and refactoring for better testability that they either get nothing done. And some people do it wrong, test for extremely specific behavior, and their code becomes impossible to change. I have also known people that try TDD but end up failing to write code that they know how to write but they don't know how to test. It is not a panacea. You have to "do it right". Contrast that with something like source control. It is hard to waste tons of time on source control that you could have saved if you just didn't use source control. It is fairly easy for even the most incompetent programmers to use source control.
gfodor 17y ago
All of these types of arguments are at the wrong level of abstraction. I've found that what makes the best programmer is not if they are a "duct tape" programmer or a "architecture astronaut" or whatever, but self awareness. They can call a hack a hack, and understand it's impact. They know when and how architecture can be improved, and when it should be improved. They can take criticism of their work because odds are, the criticism is something they already had an understanding of and can justify, or if not, they are willing to see where there was a gap in their thinking. They have a plan, and can forge a system ahead in a general direction of progress without getting bogged down in the details or taking one step forward and two steps back. You get the idea. Nobody is talking about this, arguments generally deteriorate where someone sets up a false dichotomy and then the internet collectively rips them apart. But they get ripped apart because of the falseness of the dichotomy, not because of the fact that they are looking at the wrong things altogether.
- j_baker 17y ago
  I think this is just an example of Parkinson's Law of Triviality: http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality
trunnell 17y ago
Simplicity often follows good design. Duct taping seems to be at odds with simplicity. Joel's advice to just duct tape it would lead to crappy, unmaintainable code just as often as over-design would.
trunnell 17y ago
I hate the epithet "architecture astronauts." It smacks of anti-intellectualism. We wouldn't say the same thing about actual architects: we would never deride Frank Gehry for building the http://www.guggenheim.org/bilbao http://www.guggenheim.org/bilbao saying, "wow what a waste of time, why didn't he just duct tape it... he would have finished sooner!" Physical architecture is about function as well as form; the Bilbao Guggenheim is not just a work of art, it's a highly functional building. Software architecture is similar in that better designs are more functional, more easily understood, and more easily maintained. Not everyone is Frank Gehry, but working architects can learn from him just as we working programmers can learn from Bob Martin.
- bkovitz 17y ago
  I would deride Frank Gehry. I've only been to one of his buildings, but it struck me as gratuitously zany: a very expensive and confusing way to do what could have been done better with a good ol' roughly rectangular box. Many of those classic rectangularish buildings are beautiful. Their beauty is not the kind that stuns you for a week and then becomes annoying. It's the kind that is comfortable to be around, and you appreciate more and more as you spend years living with it.
  - abalashov 17y ago
    A particular instance of Frank Gehry's work may not meet your approval, but would you go so far as to condemn the methodology of the sort of thing that is Frank Gehry's craft? The motives? The pursuit?
    - bkovitz 17y ago
      With considerable uncertainty because I haven't spent much time with his buildings (maybe there is an "aha!" moment waiting for me), yes. The motive appears to be, "How pointlessly weird can I get?" Part of the method seems to be, "Let's make this EXPENSIVE."
      - trunnell 17y ago
tptacek 17y ago
Can I ask, not to make a point but because I genuinely don't know, what software Uncle Bob Martin has shipped? What products has he worked on?
- plinkplonk 17y ago
  "Can I ask, not to make a point but because I genuinely don't know, what software Uncle Bob Martin has shipped? What products has he worked on?" AFAIK, he is the chief maintainer of Fitnesse. It is not particularly ground breaking code, and is by no means an epitome of design brilliance. That said, at least he walks the walk and puts some code out there (like Kent Beck [junit] and unlike the rest of the agile "gurus". ) Most of the agile "gurus" can't code for nuts(e.g: Ron Jeffries's "Sudoku Solver" attempt is a public example of how not to use TDD, as is his book on TDD ing which is full of pious agile homilies and terrible code). It is instructive to make a list of the initiators of the Agile Manifesto and try to find some code written by them so we can judge their skills. Mostly crickets chirping.
  - tptacek 17y ago
    I had no idea that there were famous "TDD-ers" or "Agile-ers" that were infamous for not being able to code at all. I just don't keep track of this stuff that closely. Thanks!
marcofloriano 17y ago
I disagree with his post. Maybe this kind of approach works for employees ... but when you are an entrepreneur and need to get the think done real fast not because your boss is asking but because if dont do that you are dead ... the Joel approach is much more realistic. At this scenario, the idea "Be smart. Be clean. Be simple. Ship! And keep a small roll of duct tape at the ready, and don’t be afraid to use it." is just impossible. You have to choose and you have to choose really fast.

118 points by johns 17y ago

If you're wondering whether either party in this discussion has any new insights or ideas to share that you haven't heard of before, do yourself a favor and completely ignore all of this masturbation. Here, I'll summarize the conversation: "Quit dicking around and ship!" "Sure, but you don't want me to ship shit!" "C++ sucks!" "C++ sucks, but sometimes it's a necessary evil!" There, saved you an hour.

tristan_juricek 17y ago

The same feeling hit me when reading this: the spirit of the oringal "Duct Tape" blog was right, but the specifics kind of overgeneralized. What I took away: most programmers don't have a sense of perspective on the products they're building - to most of us, it's more software then product. My nutshell analogy in Joel-speak: "software perspective is to architecture astronaut as product perspective is to duct tape programmer". The dangerous path you get on is "always shipping" without paying attention to what maintenance means. Of course, this only matters to a Real Business - you know, places that make money instead of burning it. But I find that there is a breaking point where all that code rushed out of the door starts to cost ya. And yeah, you might have to consider a revision, perhaps even adding fancy things like unit tests to figure out what the hell is breaking, or a template to reduce the code base size, whatever. But even in maintenance mode, the perspective still doesn't change. It should be about making a good product (lowering maintenance costs to speed up new development) instead of "the right way to build software".

dasil003 17y ago
Yeah, Joel is definitely, definitely wrong about unit tests. Not in the TDD/BDD/Agile koolaid kind of way, but in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity. the dangerous path you get on is "always shipping" without paying attention to what maintenance means The Joel article glosses over this too much. Why? Because this is what the unwashed masses of programmer wannabes attempt to do all day every day. You know these people, the ones that just have no business being programmers. In other industries there are standards, credentials and transparent performance evaluations that prevent people like this from even getting hired. Yet in the programming industry they make up a disturbing percentage of the work force. That's one extreme--the most common one. Joel is more focused on the architecture astronauts who need code to be a little too elegant. I know first hand that these kinds of people can really damage your ability to ship a product if given too much control, but I think it's wrong to draw a distinction and favor a "duct-tape programmer". First, because most of these people probably have the capacity to ship amazing stuff with a little guidance and the occasional reality check from more "duct-tapey" colleagues. Second, because these guys push forward the state of the art. They often see the big architecture picture in a way that others don't. They may waste a lot of time by short-term metrics, but their work is the only kind that eventually leads to long-term dividends. Occasionally some of them may be so obsessive compulsive that they just can't be forced to ship. Fine, they should go get Ph.Ds and do great things in academia, but they're still infinitely more valuable than the people who don't even really grok programming.
- holygoat 17y ago
  "in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity." His whole point is that short-term productivity is sometimes more important. No point building a product that'll be easy for you to extend in the future if you don't build it quick enough to have a future.
  - dasil003 17y ago
    My whole point is that short-term productivity doesn't need an advocate. If you're literally going to die then sure, go ahead and throw the hail mary. However in the vast majority of cases the future becomes the present quicker than anyone foresaw and then you find out that 20% time savings has now put you in a position where all future development is 50% more expensive, at which point you either (possibly) scored an amazing victory or you (more likely) handed yourself a crippling setback. You know, sort of like the situation that presumably led to the rewrite of Mozilla.
    - The_Lost_Hacker 17y ago
      However in the vast majority of cases Sorry, but that is extremely wrong. In the vast majority of cases, every bit of work you did amounts to nothing. For every successful startup, there are thousands of failures. There is absolutely no point in wasting time on ANYTHING long term until you are sure of success, whether that be attracting a shitload of users or making a shitload of money. I learned this lesson in an extremely painful way.
j_baker 17y ago
Personally, I think the key is in understanding that hacks are fine as long as they're localized. Generally, it's ok to fudge in places. But hacks shouldn't compromise the "big picture".
- dkarl 17y ago
  hacks are fine as long as they're localized That's the difference between a duct tape programmer and a genius duct tape programmer. The genius has a huge brain that envelopes the entire program. To the genius, everything is local. The non-genius duct tape programmer can't comprehend the entire program, so he just blindly hacks on local problems. When you can't comprehend the whole system at once, you have to use abstraction and good design to ensure that your locally good parts will interact to create a good whole. Compare this quote from Charles Simonyi: Right now, I have to really concentrate and I might even get a headache just trying to imagine something clearly and distinctly with twenty or thirty components. When I was young, I could imagine a castle with twenty rooms with each room having ten different objects in it. I would have no problem. I can't do that anymore. Now I think more in terms of earlier experiences. I see a network of inchoate clouds, instead of the picture-postcard clearness. But I do write better programs.
  - j_baker 17y ago
    To take this to an even more absurd level, a true genius duct tape programmer is one who knows that the rest of his team aren't geniuses and programs as such. :-)
sayrer 17y ago
didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?
- plinkplonk 17y ago
  "didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?" In those days, almost everyone writing desktop softare got their butt kicked my programmers writing multi threaded COM who worked at Microsoft, a company that indulged in blatantly illegal or semi legal tactics to do said "butt kicking". Eric Sink recalls how he had an epihpany when he came to know that Micrsoft had 1000 developers working on IE, a product that they gave away. I wouldn't judge programming ability by getting steamrollered by the MS juggernaut.
  - DrJokepu 17y ago
    By giving away Internet Explorer free, Microsoft made web browsers a commodity. Before that, commercial users had to buy licences for Netscape Navigator. I think the web greatly benefited from that move.

mikedouglas 17y ago

Uncle Bob seems to be confusing spirit with conclusion. JWZ and Joel are arguing against "[using complex technologies] for their benefits", where simpler tech would suffice. When you're designing a browser, C++ and multithreading do have benefits, but "Duct Tape Programmers" would argue that they aren't worth the design overhead when you're facing a tight deadline. Same with COM, unit tests, design patterns, etc. Obviously, Joel doesn't believe these have no benefits and that they're only used because they're cool. He doesn't endorse them because he doesn't believe they are worth it. It's fine if you disagree with the duct tape mindset, but don't construct strawmen to show "we all really agree".

branden 17y ago
I think the problem with Joel's post is that you have to read between the lines to understand what he's advocating. He knows that a strong voice makes for a more compelling blog, but that caused his message of balance and tradeoffs to get muddled. As a programmer who can engineer to a fault, I found Uncle Bob's post much more useful.
- mikedouglas 17y ago
  I'm not sure. Uncle Bob's post came off as so reasonable and moderate that I have trouble applying it to any practical situation. Joel's post drew conclusions I don't agree with (redesigning to add multithreading after the first release seems like classic 'second system syndrome'), but at least I had a fairly good idea of the personality he was describing.
psyklic 17y ago
I believe that Joel knows that "C++ and multithreading do have benefits" -- the problem is that most people do not know how to properly code C++ and multithreading. So, even if you do use them appropriately, someone will edit the code at some point and not quite understand how to use them correctly.

andreyf 17y ago

As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up. This seems logically impossible. Maybe I'm misunderstanding TDD, but at the heart of it, TDD seems to suggest you: 1) Give instructions that describe how to check the instructions you're about to give are correct 2) Give instructions This is not the right solution to the problem "I'm unable to give the computer the instructions I intend". At the very fundamental level, it clashes with DRY, and is only effective if you're very uncertain in your ability to do (2). The right solution is improving your ability to do (2) - by creating better abstractions and metaphors, not by repeating yourself.

pseale 17y ago
One of the things I like about the TDD experience is it assumes you're not a 'strong enough programmer' and works with your failings. If you're the perfect OO programmer who has memorized all APIs, TDD is worthless, because you can just bang out code the first time correctly. If you write perfect code, why bother exercising your code first in tests when you write it correctly the first time, every time? For me, it helps. I'm going to go out on a limb and say it will help you too. If you haven't tried TDD, I'd recommend attempting it at least once, maybe try running through a simple problem with a partner or at a coding dojo.
plinkplonk 17y ago
"As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up." One assertion counters another. Joel is wrong because "Uncle" Bob says so. Why do TDD zealots sound like religious preachers? No harm writing unit tests. They serve well for (a certain amount of) regression testing. The whole Test Driven approach to designing software is more dubious (but wildly endorsed by the Agile consultant crowd). More sober developers seem to disagree. From Coders at Work "Seibel: What about the idea of using tests to drive design? Norvig: I see tests more as a way of correcting errors rather than as a way of design. This extreme approach of saying, “Well, the first thing you do is write a test that says I get the right answer at the end,” and then you run it and see that it fails, and then you say, “What do I need next?”—that doesn’t seem like the right way to design something to me."

astine 17y ago

It's better to ship shit than not at all, but it's better to ship late than to ship shit. The problem is that if you ship too late, you don't ship at all.

j_baker 17y ago
As much as I hate to quote the zen of python: Now is better than never. Although never is often better than right now.
rm-rf 17y ago
I've been on the 'shipped shit' side of applications a couple times. Ten's of thousands of customers and a shiny new app that could only be described as shit. I'd have rather had the product late.
- holygoat 17y ago
  But would the customer?

wglb 17y ago

Well, perhaps uncle Bob should read not only Joel's column but also Peter's book. JWZ is not alone in that book (Coders at Work) about not using fancy stuff. C++ gets a pretty universal smackdown from all there. In fact, one of the hackers there preferentially codes in assembly, because C is not close enough to the machine. There are many nuggets there about IDE, unit testing, proof of program correctness, literate programming, design patterns. My reading of the book is that if your gig is agile or TDD or templates, you will have a cold audience in those coders. Even if you bring it on with attitude.

coliveira 17y ago
JWZ says that one of his methods to smell bad developers is finding if they are too excited about C++ and templates.

ilyak 17y ago

Joel's point wasn't that some programmers aren't smart enough to use C++ plus COM plus multithreading. He just said that humans aren't smart enough. They, however, might think that they are. Which is sad.

davidmabe 17y ago

In Joel Spolsky’s recent blog he talks about "Duct Tape Programmers". I'm not sure I trust anyone that doesn't know the difference between a "blog" and a "post".

simplegeek 17y ago

I don't use Visual Studio for work but I've used it for some side projects. What's wrong with that? Not sure why author doesn't like it. Agree with rest of the article though, to extent.

middus 17y ago
He seems to be more of a UNIX kind of guy.

ardit33 17y ago

"As for Joel’s consistent dismissal of unit testing, he’s just wrong about that. Unit testing (done TDD style) does not slow you down, it speeds you up. One day I hope Joel eventually realizes this. " Bullshit. I call TDD more like "insecurity driven development". Perfect fit for big corps, where mistakes are punished, and being fast is not really rewarded. *hence the myriad of processes to do even simple check-ins. There is much better ways to deal with it: 1. Design interfaces, that implement the features you think you need. That's like the outline of your essay. 2. Have classes that implement them (put all messy code there). Write your essay. 3. Do some functionality testing on the features that are important, and can reasonable be measured (.ie. no functionality testing/unit testing in UI stuff). And make sure you use it. Unit test may catch only some stuff. Proof read it. From my experience in my previous startups, If you have to ship in three weeks, unit testing is the very first thing that gets tossed out of the window. At the end of the day, who cares if your product has few bugs. You got to ship something. And I am saying this from experience, where a product I worked is being used by over 2million of people. Buggy? Oh yes. Did the bugs kill the overrall experience, i don't think so. If we had missed that deadline, there was huge financial ramification for the company (apart 10s millions of dollars, it was a relationship breaker with the main client). We took our time to fix some of those bugs on subsequent releases. If we had to do TDD, we probably would have never get done in time. Sure we might have found and fixed some of the bug earlier, but none of those bugs were detriment to the whole experience anyways. The only time you really should care to test about even the most minuscule feature, is if you are doing some highly financial/sensitive stuff. Most starts are not in that field anyways.

johnb 17y ago
"insecurity driven development" is probably a good alternate title for TDD, but instead of taking it at it's trollish face value it can generate a good analogy. If you start walking down a dark alley - you start feeling insecure. You've got a few options from that point. You can back out of the alley and hey, no more insecurity. A little embarrassing but you're feeling OK, you just have to go the long way round the block. You can push on through the alley in the dark - something bad could happen or you could get through fine. You don't really know until you've popped out the other side. Or you could carry a god-damned torch. Obviously when carrying a torch, you don't have it turned on all the time, just when you wander into darker areas where you're less sure of the environment. It lets you walk at full pace without stubbing your toe or getting mugged or whatever. In more concrete terms: I'm a bit of a poor-weather TDDer (same with pair programming) If i start working on something that could be algorithmically challenging, cuts across multiple layers of our app, touches something scary (like our accounting code, because i don't want to lose any of our $$$), or am just plain stumped - I write a test. It fails. I make it pass. I write the next. I make it pass. I realise my code looks like ass, I refactor. The tests still pass. I can give an actual example from this week. Our app is a large RoR app that serves multiple sites from the one codebase based on an internal DSL we have. We're in the final week of a must launch redesign (date was set because of a bunch of marketing, etc) and I get an urgent and large last minute change dropped on my desk (i'm sure you all know that feeling). I'll admit my first move wasn't to go TDD, I just went for the quick and hopeful move of quickly adding some code that looks like it should work to our DSL. It didn't. So my very next move, knowing that I have a deadline I must hit with a risky technical change, was to start writing tests. If i hadn't, I'd have to be verifying my code works by checking around 3 different pages after a server restart which is both slow and 4 layers away from the changes. So it was faster in real time. I'm not a big fan of TDD zealots, TDD is just another tool in the box. But TDD haters really get my goat. You're willfully shutting yourself out of a tool that can make your life easier, and help deliver code faster.

sutro 17y ago

Look at the surrounding website. What is being sold by Object Mentor? Training, consulting, books, advice. Not software.

jister 17y ago
True. That is why they boast on their TDD advice all the time...that developers should TDD this and that. And what happens if the project failed? Ah, the developers didn't implement TDD correctly. Period. TDD != Software
bkovitz 17y ago
How could anyone upmod that? It's pure ad hominem.
- holygoat 17y ago
  No it's not. It's an instance of "cui bono", and skepticism about credentials.
  - deleted 17y ago
    [deleted]
  - bkovitz 17y ago
    How is it not ad hominem? It's telling facts about the speaker to put down the content. Regarding credentials, we are judging the content on its merits, not deferring to Uncle Bob's authority.
  - thrdOriginal 17y ago
    The comment can be read as "you're just saying that because you sell training, consulting, books, and advice, not software." Which absolutely has nothing constructive or destructive to say about the merits of Uncle Bob's argument. Looks like an ad hominem to me.
- tigerthink 17y ago
  Let's say we are arguing about the color of Mount Everest. Joe says it's blue and Mike says it's white. Would it be relevant to the debate if Joe had never in fact seen Mount Everest? In the same way, software advice that doesn't take the form of deductive argument from mutually agreed-upon principles is largely valuable insofar as the person peddling it is experienced and honest.

lacker 17y ago

Unit testing (done TDD style) does not slow you down, it speeds you up. I do a lot of unit testing myself, but I know many programmers for whom unit testing does slow them down. Some people get so caught up in unit testing and refactoring for better testability that they either get nothing done. And some people do it wrong, test for extremely specific behavior, and their code becomes impossible to change. I have also known people that try TDD but end up failing to write code that they know how to write but they don't know how to test. It is not a panacea. You have to "do it right". Contrast that with something like source control. It is hard to waste tons of time on source control that you could have saved if you just didn't use source control. It is fairly easy for even the most incompetent programmers to use source control.

gfodor 17y ago

All of these types of arguments are at the wrong level of abstraction. I've found that what makes the best programmer is not if they are a "duct tape" programmer or a "architecture astronaut" or whatever, but self awareness. They can call a hack a hack, and understand it's impact. They know when and how architecture can be improved, and when it should be improved. They can take criticism of their work because odds are, the criticism is something they already had an understanding of and can justify, or if not, they are willing to see where there was a gap in their thinking. They have a plan, and can forge a system ahead in a general direction of progress without getting bogged down in the details or taking one step forward and two steps back. You get the idea. Nobody is talking about this, arguments generally deteriorate where someone sets up a false dichotomy and then the internet collectively rips them apart. But they get ripped apart because of the falseness of the dichotomy, not because of the fact that they are looking at the wrong things altogether.

j_baker 17y ago
I think this is just an example of Parkinson's Law of Triviality: http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality

trunnell 17y ago

Simplicity often follows good design. Duct taping seems to be at odds with simplicity. Joel's advice to just duct tape it would lead to crappy, unmaintainable code just as often as over-design would.

trunnell 17y ago

I hate the epithet "architecture astronauts." It smacks of anti-intellectualism. We wouldn't say the same thing about actual architects: we would never deride Frank Gehry for building the http://www.guggenheim.org/bilbao http://www.guggenheim.org/bilbao saying, "wow what a waste of time, why didn't he just duct tape it... he would have finished sooner!" Physical architecture is about function as well as form; the Bilbao Guggenheim is not just a work of art, it's a highly functional building. Software architecture is similar in that better designs are more functional, more easily understood, and more easily maintained. Not everyone is Frank Gehry, but working architects can learn from him just as we working programmers can learn from Bob Martin.

bkovitz 17y ago
I would deride Frank Gehry. I've only been to one of his buildings, but it struck me as gratuitously zany: a very expensive and confusing way to do what could have been done better with a good ol' roughly rectangular box. Many of those classic rectangularish buildings are beautiful. Their beauty is not the kind that stuns you for a week and then becomes annoying. It's the kind that is comfortable to be around, and you appreciate more and more as you spend years living with it.
- abalashov 17y ago
  A particular instance of Frank Gehry's work may not meet your approval, but would you go so far as to condemn the methodology of the sort of thing that is Frank Gehry's craft? The motives? The pursuit?
  - bkovitz 17y ago
    With considerable uncertainty because I haven't spent much time with his buildings (maybe there is an "aha!" moment waiting for me), yes. The motive appears to be, "How pointlessly weird can I get?" Part of the method seems to be, "Let's make this EXPENSIVE."
    - trunnell 17y ago

tptacek 17y ago

Can I ask, not to make a point but because I genuinely don't know, what software Uncle Bob Martin has shipped? What products has he worked on?

plinkplonk 17y ago
"Can I ask, not to make a point but because I genuinely don't know, what software Uncle Bob Martin has shipped? What products has he worked on?" AFAIK, he is the chief maintainer of Fitnesse. It is not particularly ground breaking code, and is by no means an epitome of design brilliance. That said, at least he walks the walk and puts some code out there (like Kent Beck [junit] and unlike the rest of the agile "gurus". ) Most of the agile "gurus" can't code for nuts(e.g: Ron Jeffries's "Sudoku Solver" attempt is a public example of how not to use TDD, as is his book on TDD ing which is full of pious agile homilies and terrible code). It is instructive to make a list of the initiators of the Agile Manifesto and try to find some code written by them so we can judge their skills. Mostly crickets chirping.
- tptacek 17y ago
  I had no idea that there were famous "TDD-ers" or "Agile-ers" that were infamous for not being able to code at all. I just don't keep track of this stuff that closely. Thanks!

marcofloriano 17y ago

I disagree with his post. Maybe this kind of approach works for employees ... but when you are an entrepreneur and need to get the think done real fast not because your boss is asking but because if dont do that you are dead ... the Joel approach is much more realistic. At this scenario, the idea "Be smart. Be clean. Be simple. Ship! And keep a small roll of duct tape at the ready, and don’t be afraid to use it." is just impossible. You have to choose and you have to choose really fast.