Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming

The Duct Tape Programmer 551

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 rubycodez ( 864176 ) on Friday September 25, 2009 @11:00AM (#29539717)

    hahaha. you know, I once had a boss that would make stupid statements like that, how he could have done xyz in minutes. one day I threw the keyboard at him and said, "you are full of shit, show me!" that stopped his b.s. bragging to me at least, though he continued to b.s. everyone else.

  • by teknomage1 ( 854522 ) on Friday September 25, 2009 @11:50AM (#29540325) Homepage
    But remember, on numerous occasions Joel has stated how much he disagreed with the plan to rewrite mozilla from scratch. For example: http://www.joelonsoftware.com/articles/fog0000000069.html [joelonsoftware.com]
  • by srussell ( 39342 ) on Friday September 25, 2009 @01: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.
  • Re:True that (Score:5, Informative)

    by thePowerOfGrayskull ( 905905 ) <marc...paradise@@@gmail...com> on Friday September 25, 2009 @01: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.

  • by Anonymous Coward on Friday September 25, 2009 @03:57PM (#29543223)

    Yeah, try this with an asynchronous distributed system that was hacked together by duct-tape-programmers. Any attempt to refactor the code pops up unexpectedly as a distributed deadlock, message loss, transaction failure. Good luck with that...

    I had this at SUN Microsystems and it was enough for the rest of my life...

  • by Lord Ender ( 156273 ) on Friday September 25, 2009 @04:40PM (#29543813) Homepage

    I realize you're joking, but here's a list of organizations that make serious use of Python:

    http://wiki.python.org/moin/OrganizationsUsingPython [python.org]

    I don't know if a list like this is being maintained for Ruby, but where I work, most of our internal business web apps, and some of our external apps, are done in ruby. Metasploit, a major app I and many others rely on for security testing, is written entirely in ruby. The folks at Engine Yard (http://www.engineyard.com/) also do serious web app hosting entirely in jruby.

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

    by Gorobei ( 127755 ) on Friday September 25, 2009 @07:57PM (#29545387)

    I still we're still writing the guide. My approach (for a massive Python installation,) has evolved towards a series of unittests:

    Group 1. These test the normal behavior of the module (add an order, cancel an order, modify on order, etc.) Should be easy enough for another developer to read and get a sense of how the module is used. Gets written concurrently with the module itself.
    Group 2. Edge, error, and pathological cases. E.g. add an order with no items, race condition on simultaneous modifies of an order. Again, should be understandable by other developers.
    Group 3. Tests that catch every real bug or problem that was reported after initial release. I don't change the code until I've added a test here that fails under the old code, then I fix the code, then the test passes.

    1 & 2 form part of the documentation. 3 is the historical record of the module.

  • by Estanislao Martínez ( 203477 ) on Friday September 25, 2009 @08:16PM (#29545479) Homepage

    It's pretty clear you don't understand what duck typing is. Go look it up and get back to us.

    I know what duck typing is. I once drank the Ruby koolaid.

    Basically, the situation where you can duck type and still get a correctly typed program is when all the objects that may be arguments share a specific type: the type of objects that can respond to the message that occurs in that point of the code. The typical statically typed languages that people use don't have a type system rich enough to express that kind of type, because they don't have a concept like "the anonymous type that is inhabited by values that respond to the 'close' message with no arguments."

    To put it in somewhat more concrete terms: every instance of duck typing can be replicated in a language like Java by using a one-method interface. The problem isn't that Java has static types; the problem is that Java makes it too costly in terms of programmer effort to create and implement interfaces; and to make it worse, which interfaces are implemented by a class is determined at compilation time, so that if you have to use somebody else's code, you're stuck with whatever interfaces their code was compiled to use. If the language had anonymous interfaces which were type-checked by the VM at class-loading time, then you could have both your duck-typing and most of your static type checking (at the expense that some problems would be caught by the class loader, but that's better than having them only be triggered when the actual code runs).

  • by fractoid ( 1076465 ) on Saturday September 26, 2009 @08:44AM (#29547815) Homepage
    The person who modded this flamebait exhibits the Dunning-Kruger effect in context of his code-reading skills.

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Working...