9 ms·

The Duct Tape Programmer

333 points by mqt 17y ago

bootload 17y ago
"He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40." This phrase comes from watching too much Eastwood (Gran Torino ~ http://www.imdb.com/title/tt1205489/ http://www.imdb.com/title/tt1205489/) The idea behind it is you can jury-rig/fix almost anything with WD40 & duct tape alone without the need for fancy expensive tools.
- ptomato 17y ago
  The use of duct tape and WD40 as basic tools certainly far predates that movie. Per the ancient quote: “All of life’s problems can be solved with two things—duct tape and WD40. If it moves and it shouldn’t, you need duct tape. And if it doesn’t move and it should, you need WD40.”
- blasdel 17y ago
  Except that both of those tools are the absolute worst at their respective jobs! Standard duct tape uses an awful adhesive that depending on the humidity turn into a gummy mess or desiccates into flakes -- either way leaving a difficult residue and not actually holding. The loose right-angle weave of the coarse fibers means that it has zero shear strength on the most common axes, and is prone to splitting when under tension. The outer vinyl layer will separate on its own in heat, leaving a mess of fibers + adhesive behind. WD-40 combines a solvent, a mild lubricant, and an adhesive (!) -- it's extremely prone to collecting grit and caking it onto surfaces. It will displace any better lubricant it is applied onto.
  - rbanffy 17y ago
    I think you make a very good point on taking Spolsky seriously.
  - bootload 17y ago
    "... Standard duct tape uses an awful adhesive that depending on the humidity turn into a gummy mess or desiccates into flakes ... WD-40 combines a solvent, a mild lubricant, and an adhesive (!) -- it's extremely prone to collecting grit and caking it onto surfaces ..." I hear what your saying but I'm talking hacks (http://www.flickr.com/photos/bootload/3961148668/ http://www.flickr.com/photos/bootload/3961148668/) not engineering ~ http://www.flickr.com/photos/bootload/3960385835/ http://www.flickr.com/photos/bootload/3960385835/
KevinMS 17y ago
"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." Like writing a custom compiler for your web app? http://www.joelonsoftware.com/items/2006/09/01b.html http://www.joelonsoftware.com/items/2006/09/01b.html After he jumped that shark I don't read anything he writes anymore.
- swilliams 17y ago
  "After he jumped that shark I don't read anything he writes anymore." ...how'd you get that quote then? Or did you only read enough to get something to complain about?
  - cubicle67 17y ago
    He wrote a multi-threaded C++ app to parse the html and return a random sentence? Rhetorical question; What percentage of an article need to be read for the article as a whole to be classified as having been read?
  - KevinMS 17y ago
    I got it from another posting right before mine. I'm sorry I offended you and your beloved coding sensei.
- asmosoinio 17y ago
  Joel did not write, not imply, that he himself is a duct tape programmer. In fact he made it quite clear in the last paragraph that these duct tape programmers are a rare breed. Maybe you never read that far though.
- kentosi 17y ago
  That article was from 2006. I'm sure that his (and many other people's) viewpoints change over the corse of 3 years.
  - elviejo 17y ago
    Noup They still use Wasabe. He mentions it often on his podcast. And I don't think it is such a bad idea. It is simply a translator from one languate to another. Like GWT (Google Web Toolkit) They program in Java however the result is 'translated' to javascript. That is how the Gmail UI was made. So no that crazy
lupin_sansei 17y ago
I sometimes feel that programming is the mathematical/logical equivalent of the kludges on this site http://thereifixedit.com/ http://thereifixedit.com/ BTW there are some great JWZ links here http://www.reddit.com/domain/jwz.org http://www.reddit.com/domain/jwz.org
dangrover 17y ago
Maybe Netscape's duct-tape programming had some side-effects though... http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- wglb 17y ago
  If you read the chapter that Joel recommends, it talks about the design patterns guys that came in and how the anti-duct tape guys had a role to play in that delay.
  - dangrover 17y ago
    I haven't read the book yet, plan to get it soon. Sounds awesome.
- wallflower 17y ago
  A consequence of those rewrite side-effects: Mozilla Firefox was forked from the rewritten Mozilla codebase > Netscape 6.0 is finally going into its first public beta...Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. http://www.mozilla.com/en-US/firefox/releases/0.1.html http://www.mozilla.com/en-US/firefox/releases/0.1.html http://www.mail-archive.com/linux-users@linux-sxs.org/msg06717.html http://www.mail-archive.com/linux-users@linux-sxs.org/msg067...
  - kentosi 17y ago
    You're confusing two different things here. Re-writing a codebase to spawn a totally seperate application is not the same as when you're doing it to re-release an enhanced version of the same application (with a bumped up version number).
ptn 17y ago
Basically, a hacker.
DanielStraight 17y ago
"Any kind of coding technique that’s even slightly complicated is going to doom your project." "They xor the 'next' and 'prev' pointers of their linked list into a single DWORD to save 32 bits, because they’re... smart enough, to pull it off." How is that not even slightly complicated?
- swolchok 17y ago
  If you're reusing that nice general list you wrote ages ago with static inlines so that there isn't any function call overhead anyway, it's trivial, because you change the "get next element" and "get prev element" functions and never worry about it again. Complicated algorithm != complicated coding technique. It's simple expression of smart algorithms.
- jerf 17y ago
  The Kolmogorov complexity of COM is, at the very least, hundreds of kilobytes of itchy, fidgety, sensitive, and complicated code. The Kolmogorov complexity of xor'ing two pointers to save 32 bits is on the order of tens or hundreds of bytes. (I'm using the term a bit loosely, obviously, but I think it gets the point across.) I suppose it depends on the limit of "slightly", but in context I think it's clear we're talking about "techniques" that are more than a three line hack in your linked list library. YMMV. (That is, I do see the point you are trying to make.) Presumably, the duct tape programmer is doing that because it is the difference between making the product go and not making the product go, not because they love bit packing. It's not a technique I'd adopt today, but Zawinski (just to choose one example from his repertoire I've read about) was trying to make machines with, say, 8MB of RAM able to read thousands of email messages. You get a bit nutty under those constraints, or you ship slow crap. There isn't much of a third choice. (Fast and featureless, maybe.) (I think I can bid lower than 8MB of RAM, too, but I'm a bit fuzzy on netscape timeframes vs. ram timeframes. I think 4.0 was in the 32-64-128MB era, putting 3.0 a ways back, but I'm not sure.)
  - DanielStraight 17y ago
    I see what you're saying, and I agree. It's not comparable to COM. I think the thing is, articles like this tend to create some idealized programmer that is just a conglomeration of attributes the author likes even if they are mutually exclusive. To me, avoiding complexity and doing bit manipulation are mutually exclusive. It's like saying you should use left shift (or is it right...?) instead of diving by 2. Ok, it may be faster. Or the compiler may just do the same thing regardless how you type your code. The point is that "/ 2" means divide by 2 to anyone at all familiar with code. Unless you have some really compelling reason to do otherwise, you should use "/ 2". Using shifts for division (or various other bit manipulation) may be how your idealized programmer shows their classical training, but don't kid yourself into thinking that bit manipulation fits into all your other ideals for programmers. Joel's idealized programmer also avoids unit tests. Are you serious? How can this possibly be a good idea? No, your customers don't care if you wrote unit tests... in the same way you don't care if your architect does whatever it is architects do to ensure the accuracy of their work. But that's just the point. You don't care (nor should you) about how they ensure accuracy. You care only that they do. So no, your customer doesn't care if you wrote unit tests, but I assure you they care if your software crashes or gives inaccurate information. Of course, no one ever creates an idealized programmer without creating their opposite. Joel's "ideally" bad programmer multiply inherits from 17 sources. Does any sane programmer really do this? No. Of course not. Why bother mentioning it? It's like saying an idealized pilot is not like those other pilots that intentionally crash their planes. Well... no one intentionally crashes a plane. Don't bring up absurd examples to prove your point. If real life doesn't prove it, then it's not a valid point. The simple fact is that when I look at my own real-life, deployed-in-production code, I find this: The code I wrote just to get a problem solved in whatever way possible (duct tape) becomes more and more of a liability as the requirements change. With the code that I spent the most time designing (assuming I eventually came up with a good design), the more the requirements change, the more I see the beauty of the design. When a change in requirements can be fixed with a find/replace, it's a job well done. Duct tape code leads to duct tape maintenance. Duct tape maintenance leads to thedailywtf.com. I have no problem with emphasizing the importance of shipping software. I have a problem with people saying "real programmers use butterflies" when they aren't writing a web comic. I don't think there's a single "real programmers" article in the universe that is internally consistence (doesn't advocate any mutually exclusive practices). Like I said, it's an ideal, an ideal constructed out of everything the author could find in their mind, whether it fits together or not. This wouldn't be a problem if the author admitted even a slight possibility of exaggeration or lack of internal consistency, but they never do. Now... I think by now I've probably exaggerated and broken internal consistency enough for one day, so I'll stop here.
fjabre 17y ago
Awesome read. I couldn't agree more. I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'... While I think eventually one would refine their product so that it uses best practices I would say that having customers and a product should definitely be a prerequisite.
- rbranson 17y ago
  Yes, thank you. The moral of the story is that you ship a product first, then you tweak, improve, and refactor it once you've got a reason to!
  - azanar 17y ago
    If you do that, you'll run a very considerable risk of wonder why version 2.0 of your product is taking so damn long to ship. The answer: all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0. Now all these have set your code in concrete, and you have to remove half the foundation to get them back out.
    - gscott 17y ago
      It is often that way anyway regardless of planning. You get into it then your needs change over time. By version 2.0 a new foundation will last longer and incorporate things people have learned from the first version.
    - alxp 17y ago
      It is always, always, always better to have a delay in version 2.0 than that a delay in version 1.0.
    - ZeroGravitas 17y ago
      But all that refactoring will be easy because of the comprehensive unit test suit you wrote. Oh wait...
timr 17y ago
I agree with the basic idea, but I think Joel is going over-the-top with the C++ hate. I've actually shipped real code that used the insanely complicated feature of C++ templates. Works great. The problem is not with a specific language or technology -- it's using the bleeding edge technology, when the boring one will do.
- deleted 17y ago
  [deleted]
Triston 17y ago
I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work. Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial release(s). Going back into the code and safely making changes or adding code with these in place reduces time. I had an application without automated testing, it cost the company almost 2000 man hours to test the system every time they made a release. Design patterns, Joel, are repeatable patterns within code. Design patterns are again to help when another developer goes into the code they can see what the heck the original developer tried to accomplish. To summarize, I would suggest you out source some code to the far east. They will get it done really fast for you. And yes it will only work 50% of the time. I love buying products that will only work 50% of the time and unfortunately I don't get to pick which 50% works.
- rbranson 17y ago
  I don't think that's the point Joel is making. At the end of the article, it really comes together. Perhaps you are too heavily focused on the specifics (unit testing, etc) instead of the overall theme. He's basically saying that while the other guys are wasting time overengineering a project, sometimes just getting to work and getting started is a much more productive approach. Joel isn't directly bad-mouthing unit testing or multithreading, but as developers we tend to think about all of these cool toys we can use and "ooooh" and "ahhhh" instead of actually shipping code. Try not to get so hung up on the specifics.
  - rimantas 17y ago
    And the guys who will have to maintain that promptly shipped code will say a lot of "wtf?" and waste 10x more time on it.
- mkramlich 17y ago
  I worked at Orbitz which has a huge Java codebase. It was complex and hard to maintain. It was loaded with abstractions, interfaces and unit tests. I believe the former was mostly due to the latter. Not to say that the latter has no merits -- there are situations and cases where they are 'net win' good things. But when overdone or done poorly they make a codebase much harder to understand, troubleshoot, extend or fix. I've seen this first-hand many times, though I notice it most often occurs in large corporate Java shops rather than with smaller companies or codebases or more nimble/concise languages.
deleted 17y ago
[deleted]
juvenn 17y ago
> 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. Shipping is a feature. A really important feature. Your product must have it. I think this does matter.
mrshoe 17y ago
Just remember that this principle applies doubly if you're a startup. And it applies doubly again if you're an early stage startup, because you're still deciding what to build at that point. Astronaut architecture is a complete waste of precious time that you don't have.
- abalashov 17y ago
  It really depends. If you put together such a kludge that you're going to have to completely rebuild it to scale past a nontrivial quantity of initial customers, you would do well to put at least a little thought into the theoretical foundation of what you're doing.
clutchski 17y ago
"And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.” By all means, ship. Do what you gotta do. But a code base that doesn't have tests cannot safely be refactored. This technical debt must eventually be paid by the product owner in cash and the code's maintainers in sanity.
- mkramlich 17y ago
  I disagree with your statement that a codebase without tests cannot safely be refactored. I've been refactoring code for 20+ years, the overwhelming majority of time without any automated tests, and I'd say offhand 99% of the time it causes no bugs, and in the occasional case where it does cause a bug (because I am imperfect and sometimes make mistakes), I almost always soon find it during the same coding session and fix it. The key is to understand the code well enough to know what effects what and how. Hold that model in your mind and you're golden. Lots of time saved not writing tests, updating them, fixing them when they break, etc. Note that this is not an argument against tests in general, just an argument for there being cases where you don't miss them and they would be a net loss if you had them due to all the extra make-work required. I think there's a lot of kool-aid drinking going on among people who themselves probably lacked the ability to do "naked" refactors well. To those folks I say, "Great, have fun storming the castle!" but don't assume that other folks who haven't drunk your kool-aid are constantly banging their head on the wall breaking the code or living in fear of mysterious hypothetical bugs due to a lack of tests. A really excellent 'old fashioned' sort of test is to just run the fricking code -- did it work? did it do what it was supposed to do? data look good? k, move on to the next one of the thousands of other problems you have to solve and tasks you have to do in life. And use version control, so if you retroactively do discover a problem, you can review the diffs, or rollback, or do a tactical patch against the branch, etc. I do agree with your statement, "By all means, ship. Do what you gotta do." And I agree that that attitude may cause you to at least temporarily incur technical debt, and you generally want to pay that down as soon as feasible. (backing out ugly hacks to replace with more elegant or easier to read implementations, etc.)
  - tezza 17y ago
pavelludiq 17y ago
Duct tape is a great metaphor. Duct tape was one of my favorite toys as a child. My dad was always mad at me for wasting it. But i can't help it if i want to build a tower from straws and duct tape, a tool thats as flexible as duct tape is empowering for a 10 year old. I propose duct tape become the new hacker symbol! :D
- SapphireSun 17y ago
  ;-) I think many other engineering disciplines would be upset if we took it all for ourselves - especially mechanical engineers.
  - pavelludiq 17y ago
    Im sure that many of us will agree that hacking is not limited to software.
tdavis 17y ago
You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tests or use higher-level abstractions doesn't automatically make him better than other types. Some of the smartest programmers I've met have been religious about TDD and strict formatting and commenting and as a result maintain and work on some incredibly large and complex systems. Did those systems start out that way? Maybe not, but after a few years and a couple rewrites I'm sure they came to the same conclusion that most programmers do when they work on things for a long time: "I wish I could go back and write some tests / automate some stuff / add better debugging, etc." I know I always feel that way. I do now, after about a year and a half of hacking together our site. I'd kill for a decent test suite and fully-automated deployment. Kill! Both styles of programming have a purpose. Maybe we'd like to avoid multi-threaded architectures, but it isn't always possible. When you have 6 weeks to launch, maybe unit tests aren't necessary, but eventually not having them will start doing more harm than good. The more I read the writings of celebrity programmers / entrepreneurs, the more I come to realize that most of what they write reads like an attempt to justify their way of thinking as being The Right Way. Why can't we all just agree there is more than one way to skin a cat and each probably has an applicable use case or two?
- Tichy 17y ago
  "I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.
  - SapphireSun 17y ago
    That's not true. Just because he never gets the chance to doesn't mean that if he had it, it wouldn't make him more efficient. If you're bailing out a ship, you might not have time to run and get a motorized pump, but you sure as hell would like one!
    - 17y ago
gruseom 17y ago
It's nice to see Spolsky get this enthusiastic about something other than his marketing, and I'm sure Peter Seibel agrees. But he negates his entire point at the end. After going on about how great duct tape programmers are, he says, don't think that means you can be one, because they're magic. (He says "pretty", but in this case pretty means magic.) To wit: Duct tape programmers have to have a lot of talent to pull off this shtick. In other words what matters is talent, not duct tape. Untalented duct tape programmers do as much damage as the untalented design-pattern programmers he scourges. So what was the point again?
- jrockway 17y ago
  The point was that he exercised for 60 minutes today, instead of 30.
- sbt 17y ago
  Agreed. I wasn't really sure what I had just read. One thing I feel fairly certain about though is that these duct-tape people will screw up a project in the long run.
  - fauigerzigerk 17y ago
    I think duct-tape programmer is not a very well defined concept. People who are careless and sloppy are the ones who will wreck a project. Duct-tape sounds too sloppy to me as well, but it could also be a metaphor for being pragmatic and keeping it simple.
- ZeroGravitas 17y ago
  I got pulled up short by that ending too. Most of the piece seems to be about the benefits of keeping it simple and doing the obvious thing that will work rather than outsmarting yourself. All well and good advice, easily applicable by anyone with the confidence to face down blowhards that would rather things feed their leet-programmer ego than actually meet a customer's need. But then it goes into not writing tests and doing complicated bit-munging to save a bit of time or space (both of which you think would be the opposite of the previous advice of keep it simple and accept your own human failings) and which is stuff that you can only get away with if you are both talented and lucky. If he dropped the last paragraph and the bit about not writing unit tests (which, the theory goes, will save you time assuming, again, that you're not a lucky genius) then this would hold together somewhat coherently.
deleted 17y ago
[deleted]
Virax 17y ago
Jamie Zawinski is not "hard at work building the future". According to his own website, he is managing the DNA lounge, and the last thing of any substance he worked on was a program to delete silence from mp3 streams (see http://www.dnalounge.com/backstage/src/archiver/ http://www.dnalounge.com/backstage/src/archiver/). He claims a copyright date of 2001-2006 for this program, which, after a quick skim, appears to be high quality. In my opinion, he is a talented programmer who has this to say about the software industry: (1999+) But now I've taken my leave of that whole sick, navel-gazing mess we called the software industry. Now I'm in a more honest line of work: now I sell beer. So, I suppose, Joel is right, in a roundabout way: Selling beer => flirtation => sex => sperm + egg = Building a future human being! But seriously, Joel is on crack.
- tsally 17y ago
  Once you build something as important as Netscape Navigator and cash out for a good chunk of money, I think it's ok to do whatever you want. Building something for the future doesn't have to be a lifelong thing.
- eugenejen 17y ago
  Jamie also worked under Peter Norvig, and this is what Peter said about Jamie: ". One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub. " -- from http://norvig.com/21-days.html http://norvig.com/21-days.html
abalashov 17y ago
I am not a fan of this kind of extreme maximalism; surely there has got to be a decent compromise? That's assuming, of course, that purely utilitarian pragmatism vs. lofty, academic architecture idealism is a valid dichotomy, and that there don't exist a variety of third ways and composite profiles. Of course, any useful generalisation that posits a continuum can be torn down, but I really think that in this case it needs doing. There has got to be a better way than being a "duct tape programmer." It seems to me that one can practice good design, architectural grace, and hold true to a variety of other tendencies that seem theoretically and aesthetically appealing (the latter is very important; every good programmer I have ever met sees an artistic aspect to programming, even if it is not necessarily the central or principal one - it is a craft) without being the guy that never actually puts out any concrete deliverables. I think this is just an angry, bitter overreaction - and a very understandable one that I fully endorse - to the dogmatism of many test-driven development acolytes and pig-headed "patterns" people.
jrockway 17y ago
Ah yes, now I know why xemacs and firefox crash so much.
GeneralMaximus 17y ago
Moral of the story: there is no silver bullet. Use some template magic when you need it, create sprawling class hierarchies if required and write tests if you think they are necessary. In the real world, purity is a liability, not an asset.
johnwatson11218 17y ago
When Sarah Palin was running for office I heard a British politician remark that Sarah Palin represented the negation of politics. She appealed to people who were fed up with politics and politicians. For some reason Joel's argument reminds me of this. He seems to have examples of over the top designs gone bad but in the end I can't find much of real value to take away from this article. Is the visitor pattern too much? What about hibernate or other ORM tools?
BerislavLopac 17y ago
"We’ve got to go from zero to done in six weeks" This is my personal pet peeve. There is the iron triangle at work again, and when one of its points is fixed you still have two others to adjust, which seems to be forgotten here. Zawinski is trying to keep the scope (i.e. what defines the "done") and is sacrificing quality; he should instead try to make his life easier by reducing both a little bit rather than cutting just one to the bone.
kschiess 17y ago
http://blog.absurd.li/2009/09/24/on_smart_boys_in_programming.html http://blog.absurd.li/2009/09/24/on_smart_boys_in_programmin...
alanl 17y ago
Basically Joel is saying that duct tape programmers are pragmatic programmers who’s priority is to get the job done. Now from my experience in the office there are very few non-pragmatic programmers, and even fewer coders who don’t want to get the job done as quick as possible. So that means that the majority of us are that duct tape programmers right? but these doesn’t fit, So what’s wrong? well I think there are different types duct tape programmer based on there how smart they are, and that only the really smart ones can successfully write systems without a single test. The remaining programmers use tests to ensure what they have done works, and also hasn’t broken something else. So given the fact that most people work in teams of programmers of varied skill levels, it makes sense to write tests. And while this might slow the 1 or 2 super smart guys on the team, it will aid the rest of the team.
scotty79 17y ago
I have friend like that and he saved my ass many times. When I was stuck trying to find satisfying solution, he was almost always coming up on the spot with something simpler then I was striving for, but upon close inspection good enough. If I pointed significant problem in his solution he either came up with fix or abandoned his idea without regret. I like to think that I design better apis and libraries than him because I concentrate much more on what I want to have and try to weed out any inconvenience, but when I can't get what I want then he comes up with the idea I actually can get and is good enough.
olavk 17y ago
Joel does not mention that Netscape code was so bad that it cost them serious credibility and customers. As a Netscape user back in the day, I did not care whether Netscape used unittests or duct tape, but I switched from Netscape to Internet Explorer because Netscape was so buggy it was painful. Over a few years Netscape code became so unmaintainable they had to start from scratch, which cost them years. Joel wrote in another famous article that this was a major mistake. However, if the code is a giant "pragmatic" mess with no architecture and no unittests, it becomes extremely hard and dangerous to refactor. IE also got a lot of mindshare among developers because it actually tried to implement some standards like CSS, which Netscape completely disregarded. Netscapes "pragmatic" alternative to CSS, <spacer>, <layer> and so on luckily died together with Netscape. Many developers started making IE-only pages because it was almost impossible to get anything to work in Netscape 4. IE6 is pretty unpopular among developers today, but this is nothing compared to how the Netscape 4 generation was reviled back in the day by anyone having to develop for it. > Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. They thought that they only had a few months before someone else came along and ate their lunch Also remember that they lost it all, and someone did eat their lunch. So maybe the their strategy should be reexamined?
- eugenejen 17y ago
  The argument ingnores a fact that if netscape did not take off and be popular, microsoft might not ever consider buying spyglass browser and expanded it into IE (Eric Sink led the spyglass team, with his memoir http://www.ericsink.com/Browser_Wars.html http://www.ericsink.com/Browser_Wars.html) and waged browser war in late 90s. What all software architects forget is, most of time, the piece of code that we wrote is to solve problems in life. Those problems have their life cycles; some are long, some are short. While we seems like to imagine the piece that we wrote will be a masterpiece as a Cathedral/Pyramid and last for 1000 years. Unfortunately that is not the case. Most of time, our programs are just solutions among solutions to a series of bootstrapping problems. So unless we have a lousy but popular solution to a problem, our potential competitors might just ignored a market and no progress happened for the field. And this is a lost to human progress. It is the same as maintaining old buildings, if condition is right, you may just tear it down and rebuild what you deem is fit by today's standard. But don't forget the original building has served its purpose. Edit: I personally have affection for Netscape 1.0. I still remembered how people in my lab in Taipei ftped to netscape's download server and waited for the moment when they uploaded the tgz file and started to download it and installed it on Sun workstations. And by using it I felt making stuffs on internet is better than studying physics and the decision changed my life.
JustAGeek 17y ago
Is Netscape really that good of an example for Duct Tape Programmers at work? Granted, they got a killer application out that was succesful for quite some time but considering the following events, that is, Netscape figuring the codebase got so bad that a complete rewrite was in order - isn't it rather an example for duct tape-programming doing more harm than good? Or am I missing something? EDIT: The fact that a complete rewrite is a big mistake, is another story, of course...
tmikew 17y ago
I would just say this for folks who don't like unit tests because it takes longer. Push yourself away from the keyboard and think about it. When one writes codes one writes unit tests in ones head or the code doesn't work. I submit that we always write unit tests. The difference is in one case we keep it so we can run it over and over, in the other case we do it anyway in our heads then throw it away. I am not convinced that writing unit tests now takes any longer. We all know it saves our bacon later. I have personally thrown out entire chunks of code except the unit tests and started from scratch to get things working again. I don't think the value of this can be understated.
jnaut 17y ago
Though the title "the duct tape programmers" may be a bit misleading but I think the essence and emphasis was on "Shipping is feature" and over engineering is not. I don't think Joel meant to say that accumulating technical debt (http://en.wikipedia.org/wiki/Technical_debt http://en.wikipedia.org/wiki/Technical_debt) is the way to go, rather he suggested/re-iterated Donald Knuth's statement on optimization: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." in his very own way.

333 points by mqt 17y ago

"He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40." This phrase comes from watching too much Eastwood (Gran Torino ~ http://www.imdb.com/title/tt1205489/ http://www.imdb.com/title/tt1205489/) The idea behind it is you can jury-rig/fix almost anything with WD40 & duct tape alone without the need for fancy expensive tools.

ptomato 17y ago
The use of duct tape and WD40 as basic tools certainly far predates that movie. Per the ancient quote: “All of life’s problems can be solved with two things—duct tape and WD40. If it moves and it shouldn’t, you need duct tape. And if it doesn’t move and it should, you need WD40.”
blasdel 17y ago
Except that both of those tools are the absolute worst at their respective jobs! Standard duct tape uses an awful adhesive that depending on the humidity turn into a gummy mess or desiccates into flakes -- either way leaving a difficult residue and not actually holding. The loose right-angle weave of the coarse fibers means that it has zero shear strength on the most common axes, and is prone to splitting when under tension. The outer vinyl layer will separate on its own in heat, leaving a mess of fibers + adhesive behind. WD-40 combines a solvent, a mild lubricant, and an adhesive (!) -- it's extremely prone to collecting grit and caking it onto surfaces. It will displace any better lubricant it is applied onto.
- rbanffy 17y ago
  I think you make a very good point on taking Spolsky seriously.
- bootload 17y ago
  "... Standard duct tape uses an awful adhesive that depending on the humidity turn into a gummy mess or desiccates into flakes ... WD-40 combines a solvent, a mild lubricant, and an adhesive (!) -- it's extremely prone to collecting grit and caking it onto surfaces ..." I hear what your saying but I'm talking hacks (http://www.flickr.com/photos/bootload/3961148668/ http://www.flickr.com/photos/bootload/3961148668/) not engineering ~ http://www.flickr.com/photos/bootload/3960385835/ http://www.flickr.com/photos/bootload/3960385835/

KevinMS 17y ago

"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." Like writing a custom compiler for your web app? http://www.joelonsoftware.com/items/2006/09/01b.html http://www.joelonsoftware.com/items/2006/09/01b.html After he jumped that shark I don't read anything he writes anymore.

swilliams 17y ago
"After he jumped that shark I don't read anything he writes anymore." ...how'd you get that quote then? Or did you only read enough to get something to complain about?
- cubicle67 17y ago
  He wrote a multi-threaded C++ app to parse the html and return a random sentence? Rhetorical question; What percentage of an article need to be read for the article as a whole to be classified as having been read?
- KevinMS 17y ago
  I got it from another posting right before mine. I'm sorry I offended you and your beloved coding sensei.
asmosoinio 17y ago
Joel did not write, not imply, that he himself is a duct tape programmer. In fact he made it quite clear in the last paragraph that these duct tape programmers are a rare breed. Maybe you never read that far though.
kentosi 17y ago
That article was from 2006. I'm sure that his (and many other people's) viewpoints change over the corse of 3 years.
- elviejo 17y ago
  Noup They still use Wasabe. He mentions it often on his podcast. And I don't think it is such a bad idea. It is simply a translator from one languate to another. Like GWT (Google Web Toolkit) They program in Java however the result is 'translated' to javascript. That is how the Gmail UI was made. So no that crazy

lupin_sansei 17y ago

I sometimes feel that programming is the mathematical/logical equivalent of the kludges on this site http://thereifixedit.com/ http://thereifixedit.com/ BTW there are some great JWZ links here http://www.reddit.com/domain/jwz.org http://www.reddit.com/domain/jwz.org

dangrover 17y ago

Maybe Netscape's duct-tape programming had some side-effects though... http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

wglb 17y ago
If you read the chapter that Joel recommends, it talks about the design patterns guys that came in and how the anti-duct tape guys had a role to play in that delay.
- dangrover 17y ago
  I haven't read the book yet, plan to get it soon. Sounds awesome.
wallflower 17y ago
A consequence of those rewrite side-effects: Mozilla Firefox was forked from the rewritten Mozilla codebase > Netscape 6.0 is finally going into its first public beta...Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. http://www.mozilla.com/en-US/firefox/releases/0.1.html http://www.mozilla.com/en-US/firefox/releases/0.1.html http://www.mail-archive.com/linux-users@linux-sxs.org/msg06717.html http://www.mail-archive.com/linux-users@linux-sxs.org/msg067...
- kentosi 17y ago
  You're confusing two different things here. Re-writing a codebase to spawn a totally seperate application is not the same as when you're doing it to re-release an enhanced version of the same application (with a bumped up version number).

ptn 17y ago

Basically, a hacker.

DanielStraight 17y ago

"Any kind of coding technique that’s even slightly complicated is going to doom your project." "They xor the 'next' and 'prev' pointers of their linked list into a single DWORD to save 32 bits, because they’re... smart enough, to pull it off." How is that not even slightly complicated?

swolchok 17y ago
If you're reusing that nice general list you wrote ages ago with static inlines so that there isn't any function call overhead anyway, it's trivial, because you change the "get next element" and "get prev element" functions and never worry about it again. Complicated algorithm != complicated coding technique. It's simple expression of smart algorithms.
jerf 17y ago
The Kolmogorov complexity of COM is, at the very least, hundreds of kilobytes of itchy, fidgety, sensitive, and complicated code. The Kolmogorov complexity of xor'ing two pointers to save 32 bits is on the order of tens or hundreds of bytes. (I'm using the term a bit loosely, obviously, but I think it gets the point across.) I suppose it depends on the limit of "slightly", but in context I think it's clear we're talking about "techniques" that are more than a three line hack in your linked list library. YMMV. (That is, I do see the point you are trying to make.) Presumably, the duct tape programmer is doing that because it is the difference between making the product go and not making the product go, not because they love bit packing. It's not a technique I'd adopt today, but Zawinski (just to choose one example from his repertoire I've read about) was trying to make machines with, say, 8MB of RAM able to read thousands of email messages. You get a bit nutty under those constraints, or you ship slow crap. There isn't much of a third choice. (Fast and featureless, maybe.) (I think I can bid lower than 8MB of RAM, too, but I'm a bit fuzzy on netscape timeframes vs. ram timeframes. I think 4.0 was in the 32-64-128MB era, putting 3.0 a ways back, but I'm not sure.)
- DanielStraight 17y ago
  I see what you're saying, and I agree. It's not comparable to COM. I think the thing is, articles like this tend to create some idealized programmer that is just a conglomeration of attributes the author likes even if they are mutually exclusive. To me, avoiding complexity and doing bit manipulation are mutually exclusive. It's like saying you should use left shift (or is it right...?) instead of diving by 2. Ok, it may be faster. Or the compiler may just do the same thing regardless how you type your code. The point is that "/ 2" means divide by 2 to anyone at all familiar with code. Unless you have some really compelling reason to do otherwise, you should use "/ 2". Using shifts for division (or various other bit manipulation) may be how your idealized programmer shows their classical training, but don't kid yourself into thinking that bit manipulation fits into all your other ideals for programmers. Joel's idealized programmer also avoids unit tests. Are you serious? How can this possibly be a good idea? No, your customers don't care if you wrote unit tests... in the same way you don't care if your architect does whatever it is architects do to ensure the accuracy of their work. But that's just the point. You don't care (nor should you) about how they ensure accuracy. You care only that they do. So no, your customer doesn't care if you wrote unit tests, but I assure you they care if your software crashes or gives inaccurate information. Of course, no one ever creates an idealized programmer without creating their opposite. Joel's "ideally" bad programmer multiply inherits from 17 sources. Does any sane programmer really do this? No. Of course not. Why bother mentioning it? It's like saying an idealized pilot is not like those other pilots that intentionally crash their planes. Well... no one intentionally crashes a plane. Don't bring up absurd examples to prove your point. If real life doesn't prove it, then it's not a valid point. The simple fact is that when I look at my own real-life, deployed-in-production code, I find this: The code I wrote just to get a problem solved in whatever way possible (duct tape) becomes more and more of a liability as the requirements change. With the code that I spent the most time designing (assuming I eventually came up with a good design), the more the requirements change, the more I see the beauty of the design. When a change in requirements can be fixed with a find/replace, it's a job well done. Duct tape code leads to duct tape maintenance. Duct tape maintenance leads to thedailywtf.com. I have no problem with emphasizing the importance of shipping software. I have a problem with people saying "real programmers use butterflies" when they aren't writing a web comic. I don't think there's a single "real programmers" article in the universe that is internally consistence (doesn't advocate any mutually exclusive practices). Like I said, it's an ideal, an ideal constructed out of everything the author could find in their mind, whether it fits together or not. This wouldn't be a problem if the author admitted even a slight possibility of exaggeration or lack of internal consistency, but they never do. Now... I think by now I've probably exaggerated and broken internal consistency enough for one day, so I'll stop here.

fjabre 17y ago

Awesome read. I couldn't agree more. I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'... While I think eventually one would refine their product so that it uses best practices I would say that having customers and a product should definitely be a prerequisite.

rbranson 17y ago
Yes, thank you. The moral of the story is that you ship a product first, then you tweak, improve, and refactor it once you've got a reason to!
- azanar 17y ago
  If you do that, you'll run a very considerable risk of wonder why version 2.0 of your product is taking so damn long to ship. The answer: all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0. Now all these have set your code in concrete, and you have to remove half the foundation to get them back out.
  - gscott 17y ago
    It is often that way anyway regardless of planning. You get into it then your needs change over time. By version 2.0 a new foundation will last longer and incorporate things people have learned from the first version.
  - alxp 17y ago
    It is always, always, always better to have a delay in version 2.0 than that a delay in version 1.0.
  - ZeroGravitas 17y ago
    But all that refactoring will be easy because of the comprehensive unit test suit you wrote. Oh wait...

timr 17y ago

I agree with the basic idea, but I think Joel is going over-the-top with the C++ hate. I've actually shipped real code that used the insanely complicated feature of C++ templates. Works great. The problem is not with a specific language or technology -- it's using the bleeding edge technology, when the boring one will do.

deleted 17y ago
[deleted]

Triston 17y ago

I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work. Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial release(s). Going back into the code and safely making changes or adding code with these in place reduces time. I had an application without automated testing, it cost the company almost 2000 man hours to test the system every time they made a release. Design patterns, Joel, are repeatable patterns within code. Design patterns are again to help when another developer goes into the code they can see what the heck the original developer tried to accomplish. To summarize, I would suggest you out source some code to the far east. They will get it done really fast for you. And yes it will only work 50% of the time. I love buying products that will only work 50% of the time and unfortunately I don't get to pick which 50% works.

rbranson 17y ago
I don't think that's the point Joel is making. At the end of the article, it really comes together. Perhaps you are too heavily focused on the specifics (unit testing, etc) instead of the overall theme. He's basically saying that while the other guys are wasting time overengineering a project, sometimes just getting to work and getting started is a much more productive approach. Joel isn't directly bad-mouthing unit testing or multithreading, but as developers we tend to think about all of these cool toys we can use and "ooooh" and "ahhhh" instead of actually shipping code. Try not to get so hung up on the specifics.
- rimantas 17y ago
  And the guys who will have to maintain that promptly shipped code will say a lot of "wtf?" and waste 10x more time on it.
mkramlich 17y ago
I worked at Orbitz which has a huge Java codebase. It was complex and hard to maintain. It was loaded with abstractions, interfaces and unit tests. I believe the former was mostly due to the latter. Not to say that the latter has no merits -- there are situations and cases where they are 'net win' good things. But when overdone or done poorly they make a codebase much harder to understand, troubleshoot, extend or fix. I've seen this first-hand many times, though I notice it most often occurs in large corporate Java shops rather than with smaller companies or codebases or more nimble/concise languages.

deleted 17y ago

[deleted]

juvenn 17y ago

> 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. Shipping is a feature. A really important feature. Your product must have it. I think this does matter.

mrshoe 17y ago

Just remember that this principle applies doubly if you're a startup. And it applies doubly again if you're an early stage startup, because you're still deciding what to build at that point. Astronaut architecture is a complete waste of precious time that you don't have.

abalashov 17y ago
It really depends. If you put together such a kludge that you're going to have to completely rebuild it to scale past a nontrivial quantity of initial customers, you would do well to put at least a little thought into the theoretical foundation of what you're doing.

clutchski 17y ago

"And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.” By all means, ship. Do what you gotta do. But a code base that doesn't have tests cannot safely be refactored. This technical debt must eventually be paid by the product owner in cash and the code's maintainers in sanity.

mkramlich 17y ago
I disagree with your statement that a codebase without tests cannot safely be refactored. I've been refactoring code for 20+ years, the overwhelming majority of time without any automated tests, and I'd say offhand 99% of the time it causes no bugs, and in the occasional case where it does cause a bug (because I am imperfect and sometimes make mistakes), I almost always soon find it during the same coding session and fix it. The key is to understand the code well enough to know what effects what and how. Hold that model in your mind and you're golden. Lots of time saved not writing tests, updating them, fixing them when they break, etc. Note that this is not an argument against tests in general, just an argument for there being cases where you don't miss them and they would be a net loss if you had them due to all the extra make-work required. I think there's a lot of kool-aid drinking going on among people who themselves probably lacked the ability to do "naked" refactors well. To those folks I say, "Great, have fun storming the castle!" but don't assume that other folks who haven't drunk your kool-aid are constantly banging their head on the wall breaking the code or living in fear of mysterious hypothetical bugs due to a lack of tests. A really excellent 'old fashioned' sort of test is to just run the fricking code -- did it work? did it do what it was supposed to do? data look good? k, move on to the next one of the thousands of other problems you have to solve and tasks you have to do in life. And use version control, so if you retroactively do discover a problem, you can review the diffs, or rollback, or do a tactical patch against the branch, etc. I do agree with your statement, "By all means, ship. Do what you gotta do." And I agree that that attitude may cause you to at least temporarily incur technical debt, and you generally want to pay that down as soon as feasible. (backing out ugly hacks to replace with more elegant or easier to read implementations, etc.)
- tezza 17y ago

pavelludiq 17y ago

Duct tape is a great metaphor. Duct tape was one of my favorite toys as a child. My dad was always mad at me for wasting it. But i can't help it if i want to build a tower from straws and duct tape, a tool thats as flexible as duct tape is empowering for a 10 year old. I propose duct tape become the new hacker symbol! :D

SapphireSun 17y ago
;-) I think many other engineering disciplines would be upset if we took it all for ourselves - especially mechanical engineers.
- pavelludiq 17y ago
  Im sure that many of us will agree that hacking is not limited to software.

tdavis 17y ago

You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tests or use higher-level abstractions doesn't automatically make him better than other types. Some of the smartest programmers I've met have been religious about TDD and strict formatting and commenting and as a result maintain and work on some incredibly large and complex systems. Did those systems start out that way? Maybe not, but after a few years and a couple rewrites I'm sure they came to the same conclusion that most programmers do when they work on things for a long time: "I wish I could go back and write some tests / automate some stuff / add better debugging, etc." I know I always feel that way. I do now, after about a year and a half of hacking together our site. I'd kill for a decent test suite and fully-automated deployment. Kill! Both styles of programming have a purpose. Maybe we'd like to avoid multi-threaded architectures, but it isn't always possible. When you have 6 weeks to launch, maybe unit tests aren't necessary, but eventually not having them will start doing more harm than good. The more I read the writings of celebrity programmers / entrepreneurs, the more I come to realize that most of what they write reads like an attempt to justify their way of thinking as being The Right Way. Why can't we all just agree there is more than one way to skin a cat and each probably has an applicable use case or two?

Tichy 17y ago
"I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.
- SapphireSun 17y ago
  That's not true. Just because he never gets the chance to doesn't mean that if he had it, it wouldn't make him more efficient. If you're bailing out a ship, you might not have time to run and get a motorized pump, but you sure as hell would like one!
  - 17y ago

gruseom 17y ago

It's nice to see Spolsky get this enthusiastic about something other than his marketing, and I'm sure Peter Seibel agrees. But he negates his entire point at the end. After going on about how great duct tape programmers are, he says, don't think that means you can be one, because they're magic. (He says "pretty", but in this case pretty means magic.) To wit: Duct tape programmers have to have a lot of talent to pull off this shtick. In other words what matters is talent, not duct tape. Untalented duct tape programmers do as much damage as the untalented design-pattern programmers he scourges. So what was the point again?

jrockway 17y ago
The point was that he exercised for 60 minutes today, instead of 30.
sbt 17y ago
Agreed. I wasn't really sure what I had just read. One thing I feel fairly certain about though is that these duct-tape people will screw up a project in the long run.
- fauigerzigerk 17y ago
  I think duct-tape programmer is not a very well defined concept. People who are careless and sloppy are the ones who will wreck a project. Duct-tape sounds too sloppy to me as well, but it could also be a metaphor for being pragmatic and keeping it simple.
ZeroGravitas 17y ago
I got pulled up short by that ending too. Most of the piece seems to be about the benefits of keeping it simple and doing the obvious thing that will work rather than outsmarting yourself. All well and good advice, easily applicable by anyone with the confidence to face down blowhards that would rather things feed their leet-programmer ego than actually meet a customer's need. But then it goes into not writing tests and doing complicated bit-munging to save a bit of time or space (both of which you think would be the opposite of the previous advice of keep it simple and accept your own human failings) and which is stuff that you can only get away with if you are both talented and lucky. If he dropped the last paragraph and the bit about not writing unit tests (which, the theory goes, will save you time assuming, again, that you're not a lucky genius) then this would hold together somewhat coherently.

deleted 17y ago

[deleted]

Virax 17y ago

Jamie Zawinski is not "hard at work building the future". According to his own website, he is managing the DNA lounge, and the last thing of any substance he worked on was a program to delete silence from mp3 streams (see http://www.dnalounge.com/backstage/src/archiver/ http://www.dnalounge.com/backstage/src/archiver/). He claims a copyright date of 2001-2006 for this program, which, after a quick skim, appears to be high quality. In my opinion, he is a talented programmer who has this to say about the software industry: (1999+) But now I've taken my leave of that whole sick, navel-gazing mess we called the software industry. Now I'm in a more honest line of work: now I sell beer. So, I suppose, Joel is right, in a roundabout way: Selling beer => flirtation => sex => sperm + egg = Building a future human being! But seriously, Joel is on crack.

tsally 17y ago
Once you build something as important as Netscape Navigator and cash out for a good chunk of money, I think it's ok to do whatever you want. Building something for the future doesn't have to be a lifelong thing.
eugenejen 17y ago
Jamie also worked under Peter Norvig, and this is what Peter said about Jamie: ". One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub. " -- from http://norvig.com/21-days.html http://norvig.com/21-days.html

abalashov 17y ago

I am not a fan of this kind of extreme maximalism; surely there has got to be a decent compromise? That's assuming, of course, that purely utilitarian pragmatism vs. lofty, academic architecture idealism is a valid dichotomy, and that there don't exist a variety of third ways and composite profiles. Of course, any useful generalisation that posits a continuum can be torn down, but I really think that in this case it needs doing. There has got to be a better way than being a "duct tape programmer." It seems to me that one can practice good design, architectural grace, and hold true to a variety of other tendencies that seem theoretically and aesthetically appealing (the latter is very important; every good programmer I have ever met sees an artistic aspect to programming, even if it is not necessarily the central or principal one - it is a craft) without being the guy that never actually puts out any concrete deliverables. I think this is just an angry, bitter overreaction - and a very understandable one that I fully endorse - to the dogmatism of many test-driven development acolytes and pig-headed "patterns" people.

jrockway 17y ago

Ah yes, now I know why xemacs and firefox crash so much.

GeneralMaximus 17y ago

Moral of the story: there is no silver bullet. Use some template magic when you need it, create sprawling class hierarchies if required and write tests if you think they are necessary. In the real world, purity is a liability, not an asset.

johnwatson11218 17y ago

When Sarah Palin was running for office I heard a British politician remark that Sarah Palin represented the negation of politics. She appealed to people who were fed up with politics and politicians. For some reason Joel's argument reminds me of this. He seems to have examples of over the top designs gone bad but in the end I can't find much of real value to take away from this article. Is the visitor pattern too much? What about hibernate or other ORM tools?

BerislavLopac 17y ago

"We’ve got to go from zero to done in six weeks" This is my personal pet peeve. There is the iron triangle at work again, and when one of its points is fixed you still have two others to adjust, which seems to be forgotten here. Zawinski is trying to keep the scope (i.e. what defines the "done") and is sacrificing quality; he should instead try to make his life easier by reducing both a little bit rather than cutting just one to the bone.

kschiess 17y ago

http://blog.absurd.li/2009/09/24/on_smart_boys_in_programming.html http://blog.absurd.li/2009/09/24/on_smart_boys_in_programmin...

alanl 17y ago

Basically Joel is saying that duct tape programmers are pragmatic programmers who’s priority is to get the job done. Now from my experience in the office there are very few non-pragmatic programmers, and even fewer coders who don’t want to get the job done as quick as possible. So that means that the majority of us are that duct tape programmers right? but these doesn’t fit, So what’s wrong? well I think there are different types duct tape programmer based on there how smart they are, and that only the really smart ones can successfully write systems without a single test. The remaining programmers use tests to ensure what they have done works, and also hasn’t broken something else. So given the fact that most people work in teams of programmers of varied skill levels, it makes sense to write tests. And while this might slow the 1 or 2 super smart guys on the team, it will aid the rest of the team.

scotty79 17y ago

I have friend like that and he saved my ass many times. When I was stuck trying to find satisfying solution, he was almost always coming up on the spot with something simpler then I was striving for, but upon close inspection good enough. If I pointed significant problem in his solution he either came up with fix or abandoned his idea without regret. I like to think that I design better apis and libraries than him because I concentrate much more on what I want to have and try to weed out any inconvenience, but when I can't get what I want then he comes up with the idea I actually can get and is good enough.

olavk 17y ago

Joel does not mention that Netscape code was so bad that it cost them serious credibility and customers. As a Netscape user back in the day, I did not care whether Netscape used unittests or duct tape, but I switched from Netscape to Internet Explorer because Netscape was so buggy it was painful. Over a few years Netscape code became so unmaintainable they had to start from scratch, which cost them years. Joel wrote in another famous article that this was a major mistake. However, if the code is a giant "pragmatic" mess with no architecture and no unittests, it becomes extremely hard and dangerous to refactor. IE also got a lot of mindshare among developers because it actually tried to implement some standards like CSS, which Netscape completely disregarded. Netscapes "pragmatic" alternative to CSS, <spacer>, <layer> and so on luckily died together with Netscape. Many developers started making IE-only pages because it was almost impossible to get anything to work in Netscape 4. IE6 is pretty unpopular among developers today, but this is nothing compared to how the Netscape 4 generation was reviled back in the day by anyone having to develop for it. > Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. They thought that they only had a few months before someone else came along and ate their lunch Also remember that they lost it all, and someone did eat their lunch. So maybe the their strategy should be reexamined?

eugenejen 17y ago
The argument ingnores a fact that if netscape did not take off and be popular, microsoft might not ever consider buying spyglass browser and expanded it into IE (Eric Sink led the spyglass team, with his memoir http://www.ericsink.com/Browser_Wars.html http://www.ericsink.com/Browser_Wars.html) and waged browser war in late 90s. What all software architects forget is, most of time, the piece of code that we wrote is to solve problems in life. Those problems have their life cycles; some are long, some are short. While we seems like to imagine the piece that we wrote will be a masterpiece as a Cathedral/Pyramid and last for 1000 years. Unfortunately that is not the case. Most of time, our programs are just solutions among solutions to a series of bootstrapping problems. So unless we have a lousy but popular solution to a problem, our potential competitors might just ignored a market and no progress happened for the field. And this is a lost to human progress. It is the same as maintaining old buildings, if condition is right, you may just tear it down and rebuild what you deem is fit by today's standard. But don't forget the original building has served its purpose. Edit: I personally have affection for Netscape 1.0. I still remembered how people in my lab in Taipei ftped to netscape's download server and waited for the moment when they uploaded the tgz file and started to download it and installed it on Sun workstations. And by using it I felt making stuffs on internet is better than studying physics and the decision changed my life.

JustAGeek 17y ago

Is Netscape really that good of an example for Duct Tape Programmers at work? Granted, they got a killer application out that was succesful for quite some time but considering the following events, that is, Netscape figuring the codebase got so bad that a complete rewrite was in order - isn't it rather an example for duct tape-programming doing more harm than good? Or am I missing something? EDIT: The fact that a complete rewrite is a big mistake, is another story, of course...

tmikew 17y ago

I would just say this for folks who don't like unit tests because it takes longer. Push yourself away from the keyboard and think about it. When one writes codes one writes unit tests in ones head or the code doesn't work. I submit that we always write unit tests. The difference is in one case we keep it so we can run it over and over, in the other case we do it anyway in our heads then throw it away. I am not convinced that writing unit tests now takes any longer. We all know it saves our bacon later. I have personally thrown out entire chunks of code except the unit tests and started from scratch to get things working again. I don't think the value of this can be understated.

jnaut 17y ago

Though the title "the duct tape programmers" may be a bit misleading but I think the essence and emphasis was on "Shipping is feature" and over engineering is not. I don't think Joel meant to say that accumulating technical debt (http://en.wikipedia.org/wiki/Technical_debt http://en.wikipedia.org/wiki/Technical_debt) is the way to go, rather he suggested/re-iterated Donald Knuth's statement on optimization: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." in his very own way.