Forgot your password?
typodupeerror
Programming

The Duct Tape Programmer 551

Posted by kdawson
from the coders-at-work dept.
theodp writes "Joel Spolsky sings the praises of The Duct Tape Programmer, who delivers programming teams from the evil of 'architecture astronauts' who might otherwise derail a project with their faddish programming craziness. The say-no-to-over-engineering attitude of the Duct Tape Programmer stems not from orneriness, but from the realization that even a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab where you're endlessly polishing the damn thing. Like Steve Jobs, Duct Tape Programmers firmly believe that Real Artists Ship."
This discussion has been archived. No new comments can be posted.

The Duct Tape Programmer

Comments Filter:
  • by K. S. Kyosuke (729550) on Friday September 25, 2009 @09:42AM (#29539505)
    ...also protect you from sellers of snake oil and fake gems?
    • by goombah99 (560566) on Friday September 25, 2009 @10:14AM (#29539885)

      ...also protect you from sellers of snake oil and fake gems?

      No but I have a one-line perl script for that.

      • by Lord Ender (156273) on Friday September 25, 2009 @11:13AM (#29540585) Homepage

        Are you referring to duck typing?

        http://en.wikipedia.org/wiki/Duck_Type [wikipedia.org]

        (For the uninitiated, this is one of the reasons Ruby and Python programmers can deliver code in a tiny fraction of the time it takes Java or C# programmers.)

        • by Anonymous Coward on Friday September 25, 2009 @11:44AM (#29540939)

          No, that is because nothing important is done in Ruby or Python.

        • Re: (Score:3, Insightful)

          by oldhack (1037484)

          And also a big difficulty doing big projects with Python - it becomes too damn unwieldy.

          Nevertheless, noodle monster bless Python. Right tool for the right job, etc.

          • by Lord Ender (156273) on Friday September 25, 2009 @01:39PM (#29542311) Homepage

            Bad programmers can write "unwieldy" code in any language. High-level, dynamic, duck-typed languages are not unique in this respect.

            The difference is, the app is up and running, ready to ship with the duck-typed languages, whereas people using lower level static languages are still writing converters and reconverters which don't add anything to the actual functionality of the app.

            • by ultranova (717540) on Friday September 25, 2009 @02:24PM (#29542787)

              The difference is, the app is up and running, ready to ship with the duck-typed languages,

              Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.

              All duct typing does is move type errors from compile time to runtime, which also means that you can never be sure if you've actually squashed them all. I truly hate that aspect of Python.

              • by Lord Ender (156273) on Friday September 25, 2009 @02:45PM (#29543065) Homepage

                To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.

                Having to fuss with every little inconsequential detail has an advantage as far as testing goes, but it does come with a great cost as well. Some would argue that dynamic/duck + extra testing has the same effect with less cost than static + less testing.

                Ruby and Python have only been "mainstream" for a few years, while static languages have been around since the ancient days. We have yet to see how high they can rise, but I'm betting they'll go pretty far--especially considering the fact that QA teams are far less expensive to business than programmers are.

                • by Estanislao Martínez (203477) on Friday September 25, 2009 @06:01PM (#29545087) Homepage

                  To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.

                  No, this is simply not like this. If a static type system compiler fails to compile the file because of a type error, then there is truly a type error in the program. The idea that some such programs would not have caused problems at runtime is dubious, because what programs can actually run cannot be divorced from which programs compile.

                  The arguments in "favor" of dynamic typing are simply misaimed. More and better static analysis of code before allowing it to execute is a virtue; the lack of static analysis and rejection of code is not an argument for dynamic type systems, it's an argument against it.

                  The sort of argument that can be made fairly against static type systems is the following:

                  1. Static type systems that are too simple tend to prevent code reuse, while those that allow it better tend to be a lot more complicated (Haskell, anybody?)
                  2. Even when a simple type system shouldn't have gotten in the way, programmers will tend to make very bad use of it. My paradigm example is that typical Java programmers tend to put way too many methods in their interfaces (when they use interfaces at all!). The more methods you put in an interface, the less likely somebody else is going to implement that interface, especially if they just need 1/4 of the methods in it.
                  3. Languages with powerful static type systems tend to also be languages with strong "closed world" assumptions, where the compiler assumes that all code and all types that will be used at runtime are known at compilation time. This tends to make it hard to develop software that does things like load plugins, or at the very least, makes it so that such programs must forfeit a good chunk of the correctness guarantees that the type system is supposed to provide.

                  So basically, static type analysis is (a) desirable, (b) hard to get right, (c) easy to misuse.

                • by MagikSlinger (259969) on Saturday September 26, 2009 @10:45AM (#29548665) Homepage Journal

                  To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.

                  Um... no. I work with a proprietary duck type language [wikipedia.org] and Java at work. Java does not catch non-errors, IMHO. On the other hand, we have to test the hell out of the duck type language because we can only find the bugs at run-time, and with the complex code we write at work, that takes a LONG time!

                  Duck typing is nice and has some nice features. I think it makes remoting such a painless thing to implement. But in practice, I do not find it is better or faster than statically typed languages. In fact, if you are working in a large team, static typing is faster because if goober over there on the other side of the floor changes his interface, he is the one who notices it and has to fix it. In the duck-type language mentioned above, I find out about it when the next nightly dev build happens and I spent half the morning fixing problems he caused.

                  Duck typing is simply different. It has certain strengths in certain situations, just as statically typed languages. I know this in an unpopular view but: the right language for the right task. Seriously, just because Python/Perl/Ruby is your Dremel motor tool doesn't mean you should remodel your kitchen and build your own cabinets from scratch with just a Dremel!

              • by weston (16146) <westonsd @ c a n n c entral.org> on Friday September 25, 2009 @07:28PM (#29545539) Homepage

                Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.

                Most of the time when I have an error, it's not a typing one. Sometimes it's something else the compiler would catch -- misspelled identifier, function or method name I misremembered (or forgot to implement), whatever -- but more often than not, I don't spend a lot of time hitting my face with my palm over a typing error.

                No, most of the time, I find that it's my logic: I only *think* I've given the computer instructions that will accomplish what I want it to do. But I've overlooked something, left out a step, forgotten a corner case, whatever.

                Having a compiler make sure my types are right doesn't generally contribute much to solving this kind of problem, at least for the common meaning of typing we're usually invoking when we're discussing this issue (e.g., typing as it's supported by languages like Java). You could argue that unit testing is kindof like a big type test (do these modules exhibit certain specified behaviors for their "type"?), and maybe there's a language that treats typing like that, which would be intriguing. But having a compiler tell me something like "class x doesn't have method y"? Not generally germane to most of the issues I have while developing, really, and even when it is, I don't really care if I discover this at run time, particularly since feedback is at least as immediate as what you'd get from a compiler if not more.

                And meanwhile, as others have pointed out, I'm spending less time writing convertors/adaptors.

                There are problem domains where I probably wouldn't use an interpreted/duck-typed language, but I find I'm more productive when I can use them.

      • What!? You can have multiple lines in a perl script?

    • by Ukab the Great (87152) on Friday September 25, 2009 @10:22AM (#29539991)

      Not really. I've seen way too much duct tape python and ruby code.

    • by Big Hairy Ian (1155547) on Friday September 25, 2009 @10:53AM (#29540371)
      My experience is the Duct Tape Programmer writes the worst kind of spaghetti code in the world. The best way to deal with someone who is over engineering the system is for his project manager & team leaders to do their job and shoot him down to size!
      • by urbanRealist (669888) on Friday September 25, 2009 @12:03PM (#29541139)
        FTA:

        forgive them if they never write a unit test, or if they xor the next and prev pointers of their linked list into a single DWORD to save 32 bits, because they are pretty enough, and smart enough, to pull it off.

        No, I don't forgive them for writing obfuscated spaghetti code and leaving it for me to maintain. Also FTA:

        Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

        I laughed out loud when I read this. I write in C++. It's my favorite language. But I can't stand these Duct Tape Programmers who are the ones casting to void * because they can't be bothered with templates. Now I know nothing of COM or CORBA, but multithreading is generally not something you have a choice about. Avoid it if you can, think very carefully about when you need to use it because of the application requirements.

        • by jgrahn (181062) on Friday September 25, 2009 @03:26PM (#29543635)

          I laughed out loud when I read this. I write in C++. It's my favorite language.

          Mine too, but I identify with Spolsky's duct tape programmers (not the term, but the idea).

          But I can't stand these Duct Tape Programmers who are the ones casting to void * because they can't be bothered with templates.

          We all set the limit somewhere ... Spolsky, JWZ, ESR and a whole lot of slashdotters think C++ is on the wrong side of that limit. I like to think they're basing that on old information, from the hype days in the 1990s when everyone had to pretend that they were developing abstract general reusable libraries rather than Getting Work Done. I think that sick attitude is mostly gone from C++ today (although some (not all) Boost libraries give me nasty flashbacks ...)

          Now I know nothing of COM or CORBA

          That is something to be grateful for,

          but multithreading is generally not something you have a choice about. Avoid it if you can, think very carefully about when you need to use it because of the application requirements.

          Sure you have a choice. You can pick a task which has no need whatsoever for multithreading, and add threads. Lots of people do this, when a sane select() loop would have been enough.

      • by computational super (740265) on Friday September 25, 2009 @12:14PM (#29541259)
        the Duct Tape Programmer writes the worst kind of spaghetti code in the world.

        That may be true... although personally, I find that when I'm really cursing some other programmer's name and wishing disease and misfortune upon him and his family, it's the work of a "ten-levels-of-inheritance deep wrappers around wrappers that wrap wrappers that generate code on the fly" overengineerer, rather than a spaghetti coder. At least with spaghetti coding, I can walk through it mentally and figure out what's going on (although it may take a while) - with "clever" code, I can't make heads or tails of it without a debugger.

        • Re: (Score:3, Insightful)

          by Jesus_666 (702802)
          Until you run into a 150 KB ten-line behemoth of a file that mixes three different languages complete with conditionals in one language containing blocks of another language with their own conditionals that contain blocks of the first language. You know you deal with a pathologically planning-averse coder when you need to draw a map on a sheet of paper just to figure out how many conditionals deep you currently are.

          Extra bonus when they somehow manage to implement an O(n^2) problem in O(n^4).
      • by Joce640k (829181) on Friday September 25, 2009 @01:19PM (#29542099) Homepage

        I bet Joel doesn't drive to work in a duct-taped go-cart .... and I bet he wouldn't drive over bridges or work in a building which wasn't designed by a proper, qualified engineers/architects.

        Out in the real world his "duct tape" programmer would be called a "cowboy builder".

        As for his ranting on C++: He's demonstrated his C++ ignorance enough times for C++ programmers to just ignore his opinion - he still thinks it's just C with added bloat. I agree that multithreading is harder than it looks but templates and multiple inheritance...? Puh-lease.

        The final nail in the coffin of the rant is in the last line where he says it's ok to avoid unit testing but that xoring two pointers together is somehow cool. If you weren't ignoring him before you should be by now.

        Summing up: Joel has jumped the shark, every article just confirms it more

  • True that (Score:5, Insightful)

    by gestalt_n_pepper (991155) on Friday September 25, 2009 @09:44AM (#29539523)

    Agile, scrum, patterns, unit tests, etc.
    .
    Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI?
    .
    Software is about money guys.

    • by Dareth (47614) on Friday September 25, 2009 @09:48AM (#29539575)

      You can't measure Synergy man, you just have to feel it!

    • Re:True that (Score:5, Insightful)

      by Chrisq (894406) on Friday September 25, 2009 @09:50AM (#29539595)

      Agile, scrum, patterns, unit tests, etc. . Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI? . Software is about money guys.

      From experience yes to unit tests. The number of times regressions have been picked up by a test bank before deployment to the UAT (user acceptance testing) system it pays for itself many times over. Patterns save time when an experienced group discusses design, but with developer turnover I get the feeling I have spent at least as much time explaining patterns to new developers as I have saved.

      • Re: (Score:3, Insightful)

        by Jurily (900488)

        According to TFA, there are times when you have to choose between unit tests and staying ahead of the competition. What would you do?

        • Re: (Score:3, Interesting)

          by plalonde2 (527372)
          I'd avoid the false dichotomy.

          Only unit test what needs to be unit tested. If it needs to be tested the testing will pay for itself. If it's simple enough that it doesn't need testing, then you're wasting your time writing those tests.

          Half the benefit of the unit tests/test-first methodology is that they force you to design even your internal interfaces in a reliable way. The other half is knowing you didn't introduce regressions in that oh-so-clever code.

          For most projects you don't need a whole lot

          • Re:True that (Score:5, Informative)

            by thePowerOfGrayskull (905905) <marc,paradise&gmail,com> on Friday September 25, 2009 @12:07PM (#29541161) Homepage Journal
            How do you determine what "needs" unit testing?

            Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.

            • Re:True that (Score:5, Insightful)

              by Chris Burke (6130) on Friday September 25, 2009 @01:14PM (#29542025) Homepage

              Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.

              Uh-huh, and then a year later, he needs to add some new and complicated functionality, but needs the old functionality to work too. He thinks he's preserving the old logic, but it has been a while and he is not in the same mindset anymore, and prior to committing the change to the repository, he runs the unit tests and -- woops! -- it fails. He goes and fixes it, now both the new and old functionality tests pass, and he checks in working code.

              And by "he" I mean "me".

              Unit tests do wonders for myself and my group. We develop a large and constantly evolving code base. And we have a saying/rule-of-thumb: There are features that are automatically tested in our check-in procedure, and there are features that are broken. How do you determine what needs testing? Well what do you want to still work a year from now? There's your answer.

              It's not appropriate for every situation, but it works for us.

        • Re:True that (Score:5, Insightful)

          by bcmm (768152) on Friday September 25, 2009 @10:13AM (#29539879)
          If somebody shipped a browser as crash-prone as Netscape was today, it wouldn't matter if it was three years ahead of the competition. People would play with it for a bit, and then use something stable. It's possible that the type of programming he's talking about works only in the specific situation that there isn't reasonable competition, yet.
          • Re:True that (Score:5, Insightful)

            by pla (258480) on Friday September 25, 2009 @10:45AM (#29540261) Journal
            If somebody shipped a browser as crash-prone as Netscape was today, it wouldn't matter if it was three years ahead of the competition. People would play with it for a bit, and then use something stable.

            Um, no, you just disproved your own point.

            Netscape did deliver a browser years ahead of the competition... And in all its crash-prone, flawed glory, people loved it. It took the web from a geeky novelty to a mainstream phenomenon. Not until MSIE 5 came out, a full five years after the first version of Netscape Navigator, did Netscape finally fall below 50% usage.

            So the moral here? Beating your competition matters more than elegance - But having a viable business plan matters even more. ;)
        • Re:True that (Score:5, Insightful)

          by NewbieProgrammerMan (558327) on Friday September 25, 2009 @10:31AM (#29540095)

          I'd say at least write tests while you're closing bugs. Having an easily detectable bug pop up again two or three releases after you "fixed" it seems to indicate (even to non-developers) that you don't know what you're doing.

        • Re: (Score:3, Interesting)

          by MikeBabcock (65886)

          According to TFA your reputation doesn't matter, just your ability to ship now now now.

          In other words, how to be Electronic Arts. No thanks.

    • Re:True that (Score:5, Insightful)

      by geekoid (135745) <dadinportland AT yahoo DOT com> on Friday September 25, 2009 @10:07AM (#29539811) Homepage Journal

      From eperson experience, I ahve seen all you list work extremely well.

      the projects took anywhere from 10 - 20% longer to go live, but all of them went out with huge success and barely any bugs. In fact one million line project went out and only had 2 bugs. Not a single one had a complaints about missing features or bloat.

      Anecdotal, yes; however I ahve been programming for a long time and I was amazed at how well it worked out. Freaking amazed.

      The problem s not that they don't work, the problem is most places don't actually implement them correctly, or have on partial buy in.

      If your turd never gets out the door, that's a people problem, not a problem with the method of development.

      Yes, software is about money in business; however management needs to begin to understand how to quantify it better. Taking 20% longer but have almost no fixes or down time after release isn't easily quantifiable, as such in is seldom considered.

      A good accountant will find away to make it quantifiable, and good management will look at the overall projects vs project done via other development methods.

      I just wrote an application, almost all of the function were just reuse of previous projects I ahve done. How does an account quantify the value of reuse?

      If you write database classes more then once, you are doing something wrong.

      • Re: (Score:3, Insightful)

        by adisakp (705706)

        In fact one million line project went out and only had 2 bugs. Not a single one had a complaints about missing features or bloat.

        Anecdotal, yes; however I ahve been programming for a long time and I was amazed at how well it worked out. Freaking amazed.

        I'm amazed you can ship a million lines with only two bugs (found that is) when you misspell "have" as "ahve" three times in a single post. There are plenty of spelling "bugs" in your post and when I get through them, you have enough grammar "bugs" that it's hard to understand half of what you're trying to say -- that fact that it's logically inconsistent doesn't help as well. Please tell me you are not a native English-speaker and that all this craziness is just "lost in translation".

        I just wrote an application, almost all of the function were just reuse of previous projects I ahve done. How does an account quantify the value of reuse?

        Reuse of code does n

    • Re:True that - NOT (Score:5, Insightful)

      by garyisabusyguy (732330) on Friday September 25, 2009 @10:14AM (#29539889)

      I manage a small team of programmers. When I first started, I 'inherited' a developer, let's call him Crufty Joe, who had worked at the company for 20 years and had developed financial and hr routines on the old mainframe and spiffy new oracle apps system. Joe had developed a lot of code, but he was always having to perform updates and corrections...

      Why? Because he was a duct tape programmer! He always got it done by the deadline, but then he spent 75% of his time maintaining the huge pile of cruft that he had left in his wake over the years.

      Well, Joe retired and I had to place two developers on his projects for the next year just to clean out all of the old '50% working' routines, in some cases we just tossed the exisiting work and started from scratch. What was really frustrating about this was that the Oracle apps have a huge, nearly incomprehensible, but extremely useful architecture that he did not even bother to leverage, but just wrote around.

      This story acts like stopping to think about what you are doing means that you are going to implement huge, stupid architectures, but in reality he is just making excuses for being a sloppy hack. I feel damn sorry for anybody that has to support this crap in the future.

      • Re: (Score:3, Insightful)

        by Aceticon (140883)

        The duct tape programmer represents those developers that "just want to do it".

        Their comfort zone is coding so they really what to start coding and "see things moving" asap. They'll work really hard, go down coding/design dead-ends and back, re-write whole sections of the code, work long hours and eventually deliver something .... that doesn't do what's actually needed (say, because a requirement wasn't double checked with the users, or the format of the data being exchanged with some other system wasn't pr

      • Re: (Score:3, Insightful)

        by Tablizer (95088)

        I'm working on slop-bucket code like that now that I inherited. It's frustrating, but having seen this odd phenomenon before, I realized something: Reactionary programmers develop better reactionary skills to compensate. Sure, they are fixing things often, but they are also fairly proficient at digging around in spaghetti and fixing it. Cleaner approaches atrophy one's skills at ad-hoc repair such that you *have* to rely on cleaner approaches. You become a less-skilled trouble-shooter.

        I'll still take the cl

      • Re: (Score:3, Insightful)

        by AxelTorvalds (544851)
        I've seen these threads the last couple days about this blog. There are a couple of things that are worth putting in to perspective. Seems we've all worked with guys who get a lot done fast and generally try to keep things simple, maybe a bit too simple, and as Joel mentioned get the go kart running and it goes fast. The big big big difference with a duct tape guy like JWZ is that he's rich. He essentially succeeded, it doesn't matter what the long term sustainability of the project is, it doesnt'
      • Re:True that - NOT (Score:5, Interesting)

        by Dare nMc (468959) on Friday September 25, 2009 @12:11PM (#29541227)

        I guess in my experience, your example doesn't really go anywhere to disprove the article. IE I had a project where we followed all the correct design principles and did 2 years of work * 5 developers for a project that was to be the future of the company. Another division had started before us a similar project with slightly different goals. The sold management on their duct tape software that met some of the spec before ours. So my project got canceled. Their duct tape software had to be completely re-written to add the remaining features (8 years later they still haven't surpassed what we had almost done.) The fact that they were done (with something) first won out. The fact that duct tape allowed them to provide the solution, and buy them the time to re-write it, in my mind showed how it makes them more successful (I did replace a bunch of their code with ours, and the correctly written code spawned other projects to use its base, so not a failure.)

        So the fact that your co-worker got the jobs, seamed to show people they needed that solution, and thus seams thats the reason you got the time to re-write them. Shows that duct tape programming "works." Even if it isn't always the most efficient method in the long run. IE this is about how many projects have just been abandoned because they were stuck in doing it the right way, where you slap something together, you got your foot in the door, and may buy the time to do it the right way.

    • Re:True that (Score:4, Interesting)

      by mcgrew (92797) * on Friday September 25, 2009 @10:18AM (#29539947) Homepage Journal

      Software is about money guys.

      Which is exactly what is wrong with software. Software should be about creating a useful tool. When you have a blacksmith who cares more about money than his craft, you have a poor blacksmith indeed. When you have a musician who cares more about money than music, he produces crap.

      No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.

      • Re:True that (Score:5, Insightful)

        by ChienAndalu (1293930) on Friday September 25, 2009 @10:26AM (#29540051)

        Software is about money guys.

        Which is exactly what is wrong with software. Software should be about creating a useful tool.

        For some people writing software is also about paying the rent and buying food.

        • Re: (Score:3, Interesting)

          by bertoelcon (1557907)

          For some people writing software is also about paying the rent and buying food.

          Do a job good enough that people want to pay you and you will be payed, but do shitty work and nobody will want to see you again. My dad always told me that about his construction but it applies here too.

          • Re:True that (Score:5, Interesting)

            by mcgrew (92797) * on Friday September 25, 2009 @02:07PM (#29542597) Homepage Journal

            Indeed. I have a friend [slashdot.org] who works in construction. His boss is a stickler for quality and tries to keep costs down as well. As a result, he has more business than he can handle while his competetitors are cutting corners, charging high prices, and going out of business right and left.

          • Re:True that (Score:4, Insightful)

            by Darinbob (1142669) on Friday September 25, 2009 @02:20PM (#29542741)
            And in software "good work" often means "shipping on time". If you have have perfect code that ships on time, that's great. If it's late though, it causes a ripple of problems down the line; your feature gets dropped from the release, customers stop waiting for that feature and buy from competitors, revenue comes up short, business units get canceled, and people get laid off, no one really cares that it would have been great code or that it was almost done.
      • Re: (Score:3, Insightful)

        by corbettw (214229)

        Which is exactly what is wrong with software. Software should be about creating a useful tool.

        A truly useful tool either makes or saves money. If you build a hammer that has perfect balance and pounds in a nail with one hit every time, someone will pay you money to have one like it.

        No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.

        More like: no wonder Windows is more popular than Windows. Linux programmers are about making cool hacks they like, Windows programmers are about making tools people actually use, and thereby make money for their efforts.

      • Re: (Score:3, Insightful)

        by lwsimon (724555)

        Money provides the motivation to do good work. A blacksmith who cares so much about his work he redoes everything 6 or 7 times until it is perfect is a blacksmith who will soon be begging for food.

        A programmer who produces shitty code for money was never capable of producing quality code.

    • Re:True that (Score:5, Insightful)

      by h4rm0ny (722443) on Friday September 25, 2009 @10:21AM (#29539983) Journal

      I'm probably a "duct-tape programmer" in some ways. How did I become one? By learning everything I could about being an "architecture astronaut" first.

      You learn how to do things properly and then you know when and when not to step back from that. If anyone RTFS and says to themselves they don't need to have a good solid understanding of the principles of software design or even a grounding in some of the popular modern methodologies. The linked article is full of colourful metaphors about go-karts and WD-40. Making your argument by metaphor is usually a bad sign - you use them for people who would have trouble understanding the subject if you just stated the case plainly. I hope that's none of us. The article writer seems to see some great division between those who "wield their WD-40 and duct tape elegantly even as their go-kart careens down the hill at a mile a minute" and those who "are still at the starting line arguing over whether to use titanium or some kind of space-age composite material". Well the division between those two groups isn't normally one between two sets of people, but between two environments and resource levels. In an ideal situation, I'll create a rigorous specification and use that as the formal basis for my unit tests and do things by the book. Sometimes I find myself "careening down the hill" because I'm suddenly dumped a big, live system and told "make these vaguely described modifications by yesterday". And I'm the same individual. I'll tell you what I want to see if you're in that latter environment - I want to see someone who understands what corners they are cutting and when to do so and when they can't. Same goes for some of the project management methodologies. You don't have to do things by the letter of the law of Agile development or whatever, but if everyone in the group understands the principles, it can streamline things.

      Being better than the rest at anything doesn't come easy. This stupid article has some metaphorical "duct-tape programmer" who doesn't need to bother with the "achitecture astronaut" stuff because they're a whiz with their "WD-40". Enough with the metaphor. Show me the real instances of people who are better than others because they don't know about the theory.

      Some articles are stupid. This is one. It's a load of overblown metaphor and hypotheticals. Ironically enough, it falls into the trap of dealing only in hypothetical and idealised situations that it lambasts some programmers for. Sure - if you're up against a tight deadline and in the midst of a melee of programmers, don't waste two weeks drawing UML diagrams and Gantt charts. But that sort of judgement has nothing to do with not knowing the principles of software design or project management. Banging out a quick website might be a case of shifting images left and right from day to day based on customer feedback. But real programming is most definitely not a "downhill go-kart race". It's about producing maintainable, reliable code that meets the customers' needs. And if you see someone who looks like they're gluing brilliant code together on the fly with "duct tape", you'll probably find they're someone with a lot of experience and who understands the theory well enough that you don't notice them using it. As Ovid said: "Thus by art, is art concealed." In other words - they make it look easy, because they're good.
      • Re:True that (Score:4, Interesting)

        by EastCoastSurfer (310758) on Friday September 25, 2009 @10:55AM (#29540397)

        Exactly. All of Joel's articles about about good to expert developers. More than likely the people he describes could use any tool or methodology and ship correct, working software.

        This reminds me of when people try to copy a particular athletes workout or diet. Most professional athletes are genetic wonders and many succeed at their sport not because of their workout and diet, but in spite of it.

  • my employer's fault (Score:4, Interesting)

    by rubycodez (864176) on Friday September 25, 2009 @09:44AM (#29539525)

    my employer knows I can whip out a fast 4,000 line (but ugly, no artistic talent) web portal or e-commerce app in a month when it should be a 20K line project done by a team, so that's what we do. dangerous I think, we handle real money with that shit.

  • by smack.addict (116174) on Friday September 25, 2009 @09:45AM (#29539549)

    The "duct tape programmer" is just as dangerous as the "astronaut architect".

    What distinguishes good architects from these fools is this:

    A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.

    • Re: (Score:3, Insightful)

      by Jurily (900488)

      A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.

      Which is entirely subjective by definition, so we're back to the basics: a good programmer writes working programs.

      • by Jurily (900488) <jurily&gmail,com> on Friday September 25, 2009 @09:56AM (#29539677)

        After reading the article, there's nothing we didn't know before: release early, release often. But here's the killer quote all of you need to duct tape somewhere in your office right now:

        Duct tape programmers dont give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.

        • Re: (Score:3, Insightful)

          by xleeko (551231)

          Duct tape programmers dont give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.

          Exactly. Many posts will go on about how having a good architecture will make it easier to maintain in the long run, and other such things, but it all comes down to one thing:

          TIME

          If your code is useful, it will be used, you will get revenue (hopefully!), and you will have the TIME to improve things, clean up code, write unit tests, and all of the other things that are good and proper in life, but which only indirectly benefit the end used. This is the fundamental opportunity cost for software.

        • Re: (Score:3, Insightful)

          by radtea (464814)

          The killer (literally) quote for me was:

          When you are done, you might have a messy go-cart, but itâ(TM)ll sure as hell fly. ..ONCE.

          I guess the last word got edited out.

          I'm all for the least formal processes consistent with the production of reasonable quality software shipping on schedule using the resources you have available. But anyone who has had to maintain the code written by cowboys (which is what DTP's are) knows how much damage their unbridled attitude can do to a company.

          The article acknowled

    • by khakipuce (625944) on Friday September 25, 2009 @10:00AM (#29539713) Homepage Journal
      It's all about the people, a good developer (and a good architect) can use anything from a duct tape approach to a full-on methodology based life-cycle depending on the scale, complexity and critcality of the job in hand. You cannot use the same approach for building a sky scraper that you might use for building a garden shed.

      Several issues cloud this mix:

      • Non technical management really struggle to tell genuinely good developers from braggards and people who must be good because they are weird
      • Architects and analysts want fashionable things on their CVs as much as developers do, so they push towards the newest buzz because their next job may depend on it

      At the bottom of every successful development are a few people who just get on and write the code, it's where it actually happens. Ever see a hole in the road where one guy is down the hole with a shovel, and 4 others are stood around the top? I'm the guy down the hole, have been down coding holes for 20 years and pretty much every project I have started coding, I have finished and delivered, some where big methodology driven things, some where me against the world with a couple of weeks to deliver. But get keen interested and pragmatic people on the shovel and the job gets done

    • by RingDev (879105)

      I'm completely with you on that one. What Joel is effectively lobbying for is what I've long termed "Shit and fix" coding. You write something dirty but quick to meet the minimal needs of the project. You have non-existent testing, inconsistent modularization, and a maintenance nightmare that crops up every 6 weeks as the application breaks or users request a functional change.

      After a few years the application is such a mess and original knowledge sources are so far gone (documentation? what's that?) that t

    • Re: (Score:3, Insightful)

      by johnlcallaway (165670)
      What a bunch of bs...putting labels on things and trying to force people into tiny boxes.

      I've been writing code for 30+ years. I've seen all of these disciplines come in and out of favor.

      Each started with a simple concept, and was then perverted into something so that people who couldn't code could design and run projects and get paid more than the coders. Agile programming was the closest to anything useful, then it too was perverted with a bunch of useless rules and methodology structures that every
    • Re: (Score:3, Interesting)

      by 5pp000 (873881) *

      A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.

      Agreed. I have a guy on my staff who is constitutionally unable to cut corners. The upside is, when he says the feature he's working on is done, by god, it's done. I can't remember the last time we found a bug in his code. The downside is, it takes him a long time, and sometimes we would really like to have the first 80% of the functionality done quickly so that other people could start to bu

  • by freddled (544384) on Friday September 25, 2009 @09:48AM (#29539579) Journal
    I agree with most of Joel's post. What bothers me with this kind of thing is that there are a lot of idiots out there just waiting for an excuse for their poor standards. For every real Duct Tape Programmer there are ten buffoons who will now take that label for themselves. But hell they shoudln't be hard to spot.
  • False dichotomy (Score:5, Interesting)

    by ciggieposeur (715798) on Friday September 25, 2009 @09:50AM (#29539599)

    I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.

  • Industry Software (Score:3, Insightful)

    by Jazz-Masta (240659) on Friday September 25, 2009 @09:52AM (#29539611)

    Wow....praises for everything that is wrong with programming.

    I believe in a 100% good project, and somewhere around 97%+ good project. If it can't be delivered, then you're not smart enough, or it's not possible.

    Of course, I think he means something along the lines of industry software.

    I work in the auto repair industry as a system administrator. We have 20 industry specific programs. They fall into two categories:

    1. Programs developed by companies within the industry with no real programming experience. IE. Auto Shop gets smartest guy to learn how to program - builts program...these are the programs that are 50% good. Poor programming practice, unstable, but overall, on a good day, works well enough to increase efficiency beyond that of a pen/paper.

    2. Programs developed by professional programmers with no industry experience. These programs are polished, stable, run fast. The problem is, since the programmers have little or no industry experience, there is an obvious disconnect in the work process within the program. This results in features we don't need, or things we need that are absent.

    Overall, as a system administrator, #2 are better for me, because they work. #1 are better for the workers themselves.

    We have one program that "tracks changes" by polling every file on the hard drive constantly. Starts at the top and works through every file and starts again. We have a server dedicated to this, chews up a 4-core processor. When asked about it, they said there was no other way to do it...uh huh...this is the #1 approach.

  • by afree87 (102803) on Friday September 25, 2009 @09:57AM (#29539679) Homepage Journal

    Why is it that whenever I read an article by Joel I feel like I'm being talked down to?

    • Becasue Joel is an ass.

      Seriously, he is an ass, and is often wrong.

    • by Tridus (79566) on Friday September 25, 2009 @10:31AM (#29540097) Homepage

      Hey, it's a great piece of advice if ex Duke Nukem Forever programmers read the article!

    • by Taevin (850923) * on Friday September 25, 2009 @10:42AM (#29540227)
      In this case, I'm left wondering what the fuck just happened? like when someone from marketing comes by my desk with a slurry of buzzwords and technical jargon they don't understand, but it's sure to make my code rock solid. Seriously, I usually like his articles, but what the fuck is he on about?

      He starts out with a good premise, that as programmers we tend to want to over-engineer stuff and that is something we should try to avoid because it adds unnecessary cost to a project. Then he apparently has a brain hemorrhage and starts dumping on a whole host of invaluable software tools that actually increase productivity and reduce errors, both of which help you ship your code faster.
      • C++ is too hard? I admit it's no longer my first choice of language, but seriously? How much software (enterprise-class, even) is written and continues to be written in C++? I'd wager quite a bit.
      • Templates are too hard? I sincerely hope he's referring to jackasses that try to write an entire program solely out of templates and not the code reuse and simplification they offer. If he's actually supporting the kind of jackass that copy-pastes everything so there are a dozen different copies of a file with 1 change each (previously, I've referred to this kind of programmer as a Duct Tape Programmer in my head)... then fuck you, Joel, that guy is in the cubicle next to mine and I'm the one that has to fix his shit!
      • Multithreading is too hard? When you first heard about it, maybe. Yes it requires a bit of a mental shift from blowing through your whole process in one god-awful, huge, slow loop but asynchronous processes are not rocket science.

      And what the hell is he talking about with "those breathtakingly good-looking young men"? Homoeroticism aside, what does this have to do with anything? The only thing I can see is that he's saying these guys can get away with horrific things (e.g. not writing unit tests, pointer voodoo--wait, I thought we weren't using C++-like languages because they're too hard and you can't ship quickly enough), simply because they are pretty and/or smart. I thought this was also how people got away with over-engineered projects too? The smart, charismatic guy proposes a solution that's over-the-top but everyone is too busy being in awe over his intelligence or their desire to fellate him that no one notices.

      Am I way off-base here? As I said, I usually like reading Joel's stuff and I feel like I've learned a few things from his articles but after this I'm left wondering where he's getting access to such fine recreational drugs and hot, smart programmer guys.

  • is the duct tape manager

    trying to hop in his chair to the phone, arms bound to the armrests with duct tape, screaming MMMMPH MMMMPH through the glorious dull shiny grey of...

    what were we talking about?

  • by readin (838620) on Friday September 25, 2009 @10:01AM (#29539733)
    Scenario 1: Your client needs an application that will accept data input for approximately 400 different forms, allow those forms to be validated using some rules that are simple and others that are very complex, and put those forms through a fairly standard work flow.

    Scenario 2: Your client needs an application that has 5 different forms used for very different purposes whose data will be processed in very different ways.

    In Scenario 1, you had better do some engineering up front to save you from custom coding the parts of those 400 forms that could have been "over-engineered" into templates, base classes, and interfaces.

    In Scenario 2, it makes sense to duct-tape.
    • Re: (Score:3, Insightful)

      by bjourne (1034822)

      No. In scenario 1, what should be done is trying to get the customer to reduce the problem. It is unlikely that the customer regularly deals with 400 different forms, much more likely is that at most 5 forms stands for 99% of the traffic and the other 395 are one-off's much to rare to spend time on. The correct approach is to identify those 5 forms, implement the processing for those forms as quickly as possible and then evaluate if the client is happy.

      Then when the system has been delivered, you may refact

  • by ansible (9585) on Friday September 25, 2009 @10:11AM (#29539857) Journal

    Curious that JWZ and his time at Netscape were particularly lauded here.

    It's quite likely I'm being a bit snarky here... but Netscape lost the browser wars just a few years after they hit it big. And the core code of Netscape Navigator was bad enough that they eventually abandoned it around 1999 with the start of the Mozilla project.

    Now don't get me wrong, it was only through the herculean efforts of guys like JWZ at Netscape that allowed them to ship a product at all. And certainly it made him and some of the founders a lot of money, which is a valid measure of success in business.

    But to point to that particular code base as an example we all should follow? I don't think so. Certainly, choosing C++ then (or now in my opinion) is a mistake. And I've definitely seen people get overly rambunctious with architecture... especially in the Java world. But I think that's mostly the result of programming languages sucking as much as anything else. That and most people just aren't that good at design. Mostly meaning that when they've come up with a bad design themselves, they can't admit that and then really do what it takes to try and fix it. Of course, in the business world there are always severe time / money constraints, so that makes it real hard. And that's when not having unit tests hurts more... because it is harder to make significant changes to the code and have some assurance you didn't make mistakes.

  • by amn108 (1231606) on Friday September 25, 2009 @10:12AM (#29539861)

    Duct tape programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it. Mission critical applications, like those used in health "industry", expensive satellites and other kind of space vessels, tunnel digging machines and what not - everything that just cannot fail - will not really benefit from Joels so cleverly coined "duct tape programmer" character. Not sure if Joel included these areas as applicable for the "duct tape programmer" attitude, but I just wanted to say I don't think they are. Let duct tape programmers develop Photoshop, and all those benemoths of software that runs slower the faster machines we throw at them, occupy more space for the same set of features and so on and so on - probably nobody notices that anymore, as we all are sworn to content. But the few areas where software quality makes it or breaks it, Joel is off the mark, IMO.

  • by Alkonaut (604183) on Friday September 25, 2009 @10:18AM (#29539941)

    Shipping is easy. Any idiot can whip something together that solves a problem, ships on time etc. That is rarely the issue. The issue is doing it in a fashion that will scale, be extensible, modifiable, understandable, high performing... the list goes on.

    Given enogh time, any idiot could also make a system that is polished and architected to the point where it is fast, modifiable and extensible, and long overdue.

    Bottom line: the whole skill of this business is delivering something that is architected enough while still meeting the deadline. In my experience, the necessary timeframe to deliver something long lasting and well architected is around five to ten times the time it would take to just solve the problem (tm). Of course many business exist today because they managed to release something to make money. The biggest mistake of many startups is probably polishing too much and not releasing early enough. The biggest mistake of those who DO make it past the first release is to not throw the first solution away and start over if it was something duct taped together.

    • Everyone seems to be taking this article as "do anything it takes to ship" and saying that's a horrible attitude.

      Your comment is the first I've seen that seems to be more along my understanding of the piece. Duct Tape Programming is about getting what is needed done and building from there.

      "I need a website that lets people share videos".

      So what do you do? Do you make a little site that serves flash videos? That's Duct Tape Programming.

      Making a little site that takes videos and catalogs them and tries to analyze them for similarity and has editing tools and needs to be able to scale to 20 computers and... That's the problem.

      When you start your site, it's OK to have it not be able to instantly scale out to 10,000. Sometimes it's better to get the basic features there and build them up and fix them as you go. Not everything needs to be there from day one. Not everything needs 3 layers of abstraction because it's "what people do".

      As your program goes on, you clean it up, add abstractions where needed. The first version of Word for Windows didn't look ANYTHING like the current version. If you are going to make a new word processor, you go after the old version, not aim at the sky.

      Your understanding of his post agrees with mine. This isn't about a system to last 20 years, this is about a system to fix things NOW while you make it better so your users don't have to keep doing things by hand for 6 months while you try to figure out why your framework build on another framework isn't interacting correctly with some other thing.

  • by JohnWiney (656829) on Friday September 25, 2009 @10:19AM (#29539951)
    is Release 2.
  • by diamondsw (685967) on Friday September 25, 2009 @10:24AM (#29540033)

    My respect for him ratcheted down quite a lot. Yes, you must ship (who knew?). That's what milestones and deadlines are for, so keep overarchitecting and feature creep from occurring. However, I would NEVER want to let a "Duct Tap Programmer" near any project that I would ever have to modify, maintain, or extend. You know, something that isn't completely trivial.

    • Re: (Score:3, Interesting)

      by The Raven (30575)

      Refactoring is an art that all programmers should cultivate. It turns shitty code into nice code, without breaking it or losing all the bug-fixes that have been hacked in over the years. In most cases, ugly code needs refactoring, not rewriting.

  • by Aceticon (140883) on Friday September 25, 2009 @10:32AM (#29540111)

    I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.

    The typical evolution towards wisdom in Software Engineering goes like this (simplified):

    • Starting by making small programs or programs supposed to be used only once (i.e. school assignments)
    • Transition 1: Discovery of code reusability, the problems with copy & paste coding and how using methods lets you partition your code into more easy to understand blocks - this is when one transitions beyond junior developer
    • Transition 2: Discovery of the concept of software design and how it makes for more adaptable code which is easier to understand and how it helps main complexity small as the size of the program increases - this is when one transitions into junior designer
    • Transition 3: Discover that there is such thing as too much design. That over-designing decreases maintenability, makes the code harder to understand by others and by oneself in the future. That the flexibility that the real world will require from the code will rarely match one's initial idea of what should be made flexible during design and that trying to create a top-to-bottom design that covers all eventualities actually results in an inflexible system. Above all, discovery of the value of the KISS approach: don't design/implement a specific something now because you think you will need it later, it is often easier to do it then if you do actually need it and you probably won't need it and are just making for big code instead of useful code. At the same time discover that newer isn't always better when it comes to software tools, languages and frameworks and that coolness and hype are really bad things to focus in when choosing something to use in an professional IT project - this is how you get medior designers and senior developers
    • Transition 4: Discover that creating software is actually a process not an act. That a lot of things serve as feed-ins to the actual design and development of software and a lot of things feed out from it. That software isn't just made, it lives, evolves and gets changed. That making an application is easy (no mater how big and complex) and making the right application which does what's need in the right way for the users of the application is what's hard. That the quality of your feed-ins (requirements, analysis, time, people and all manner of preparations) is much more relevant to the success of a project than the code or the design. That over the long run, the true quality of the code and design is measured by how easy it is to regression test, maintain, support, extend and by how fast new designers/developers can pick up the code (which are some of the feed outs) - this is how you get senior designers and technical analysts.
    • Transition 5: Discover that the applications your develop are part of an ecosystem. That software talks to software that talks to software. That many applications need to do many of the same things, only in slightly different ways. That standardizing (up to a level) things like certain kinds of exchange of information between applications or the kind of libraries used for certain common functional areas (such as multi-system logging, single-sign-on, messaging) will make for increased overall productivity and maintenability (develop and maintain a single implementation for each and distribute it as a library). Discover that standardizing on a reduced number of mature programming languages makes it easier to find people to work with them and move people around to different projects and systems - this is how you get technical architects

    At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.

    I would hardly call a junior designer type "architect".

  • by dunkelfalke (91624) on Friday September 25, 2009 @10:56AM (#29540411)

    Well, I am - more or less - a duct tape programmer, coming from the embedded field of work.

    Two months ago I took a Java training course, never bothered to learn the language right before. One of the students at the training was a woman in her mid-forties, former quality assurance, with a wish to develop software. Last time she has written real code by her self was at the university 20 years ago. After that she only has read other people's code, tested it, found bugs there.

    After a couple of days of introducing Java and the whole OOP concept, the teacher gave us some exercise. I don't remember what it was exactly now. What I do remember is that I hacked some code together, not bad at all, with lots of features, much more than it was needed, but since I was so fast, I was very smug about it.

    Then the teacher showed my code to all students first, said it was a pretty nice solution with some tricks he never had thought of. Then he showed us her code. That woman had neatly written the task down first, planned everything carefully on paper and then implemented it, with lots of comments and an extremely clean and well-engineered code. Her solution wasn't quite as sophisticated as mine, but the code was so much more readable...

    The teacher said that such code was the way to go, and as smug as I was over my solution, I had to admit that her job was much better done. Sure, features are great but clean, maintainable and well-planned code trumps in long term.

  • by eagee (1308589) on Friday September 25, 2009 @11:28AM (#29540769)
    It's called the video game industry. That kind of methodology works there because you're generally not going to be maintaining the code base once it ships. There are three types of people you need to have a viable and successful team:

    1. People who can do abstractions, design, and estimation.

    2. People who can implement those designs (Duct Tape programmers are perfect for this).

    3. People who can do a little of both.

    I call bullshit on any one of these groups pointing the finger to the other and saying, "My way is best". If you had an office of nothing but designers you'd have a different but similar set of problems.

    I've seen projects run only by duct tape programmers fail miserably in the field when extensibility and maintenance are required, but when we added a designer to that same team and rewrote the same project we delivered a bug free implementation with a 10 fold performance increase, and no significant bugs. That wasn't magic, it was just taking the time to do the damn thing right (and no more time than that).
  • by srussell (39342) on Friday September 25, 2009 @12:03PM (#29541141) Homepage Journal
    I keep seeing this "good enough" meme going around.  At a company meeting, recently, management was espousing the same crap.

    I can only hope that these people are plagued with "50%-good" products.  50%-good tires, that blow out ocassionally, causing an accident.  Maybe Joel would like some 50%-good surgery, or a 50%-good pacemaker.  How about getting to fly in 50% good airplanes for the rest of his life?

    I'm not surprised that most of this bullshit is coming out a culture in which Walmart was able to become the success it has.  We needed something for a weekend project recently and bought the materials from Walmart, because it was closest.  What poor quality crap.  It'll all need to be replaced in a year, contributing to landfill and wasted resources.  I'm not going purchase from Walmart any more, and I'm not going to spend money on half-baked, crap-quality software, either.

    Word gets around about quality.  It's the American auto-maker's nightmare right now.  Ford, Chrystler, Chevrolet... they're all struggling to reverse decades of built-up public perception about poor quality, even when some of them are actually making fairly decent cars right now.  It isn't quite the same with software; Microsoft has been making crap software for, well, ever, and they're still dominant.  But I think that if you take the monopoly factor out of it, software companies *do* suffer from delivering half-assed product to their customers.
    • by dominator (61418) on Friday September 25, 2009 @05:35PM (#29544869) Homepage

      Good enough means good enough. It's not 50%. It's not 80%. It's whatever is the powers that be decide is the appropriate trade-off between competing interests (i.e. time to market, cost of deployment, $ paid to developers, estimates of the cost of future bug fixes, ...). If the market doesn't accept the product, it only means that their definition of "good enough" was wrong, not that there isn't a different "good enough" that the market will embrace.

      "Good enough" for the software that runs a nuclear reactor or the space shuttle is probably near 100%. Pace-makers, surgeries, and pharmaceuticals failing? It's been known to happen. Sure, maybe only in 1/10000 cases, and only if you don't have a pre-existing condition. So, good enough is maybe five nines there. "Good enough" for that $1 umbrella you bought at Wal-Mart probably means something entirely different.

  • by Animats (122034) on Friday September 25, 2009 @01:07PM (#29541907) Homepage

    First off, Jamie Zawinski no longer programs much. He runs a nightclub. [dnalounge.com]

    Second, Joel Spolsky isn't exactly a big name on programming. He's better known as a blogger than a developer. He runs a little company that makes a desktop project tracking tool. That's not rocket science. We're not hearing this "duct tape" stuff from people like Dave Cutler, who designed VMS and Windows NT. Or lead developers on MySQL. Or big names in game development.

    Spolsky is taking potshots at the template framework crowd. He has a point there. I've been very critical in that area myself; I think the C++ standards committee is lost in template la-la land. The real problem with C++ is that the underlying language has a few painful flaws for historical reasons, and attempts to paper those flaws over with templates never quite work. (Read up on the history of auto_ptr to understand the pain.) But that's almost a historical issue now. Newer languages such as Java and Python aren't as dependent on templates as is C++. If you get the basic language design right, you don't need templates as much.

  • Duct tape sucks (Score:4, Insightful)

    by ShannaraFan (533326) on Friday September 25, 2009 @04:25PM (#29544235)

    We have a whole department full of duct tape developers, writing Business Objects reports and other BI-type code. They can't write efficient database queries to save their asses. As one of the production support DBA's, I get the pleasure of debugging/tuning their crap after it hits production and won't run. Just yesterday, after one of the production Oracle machines fell over, we discovered a query that was piping a whopping 2.4 PETABYTES of data through a SELECT DISTINCT clause. Considering the database itself is less than 300GB, we found this rather interesting. When challenged, the developer responsible for the query says "It should only return about 10 rows". True, if it ever finishes applying the DISTINCT.

    Ship first, tune later, I love that philosophy...

The ideal voice for radio may be defined as showing no substance, no sex, no owner, and a message of importance for every housewife. -- Harry V. Wade

Working...