4 ms·

The same feeling hit me when reading this: the spirit of the oringal "Duct Tape" blog was right, but the specifics kind of overgeneralized. What I took away: mo

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

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

dasil003 17y ago

Yeah, Joel is definitely, definitely wrong about unit tests. Not in the TDD/BDD/Agile koolaid kind of way, but in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity. the dangerous path you get on is "always shipping" without paying attention to what maintenance means The Joel article glosses over this too much. Why? Because this is what the unwashed masses of programmer wannabes attempt to do all day every day. You know these people, the ones that just have no business being programmers. In other industries there are standards, credentials and transparent performance evaluations that prevent people like this from even getting hired. Yet in the programming industry they make up a disturbing percentage of the work force. That's one extreme--the most common one. Joel is more focused on the architecture astronauts who need code to be a little too elegant. I know first hand that these kinds of people can really damage your ability to ship a product if given too much control, but I think it's wrong to draw a distinction and favor a "duct-tape programmer". First, because most of these people probably have the capacity to ship amazing stuff with a little guidance and the occasional reality check from more "duct-tapey" colleagues. Second, because these guys push forward the state of the art. They often see the big architecture picture in a way that others don't. They may waste a lot of time by short-term metrics, but their work is the only kind that eventually leads to long-term dividends. Occasionally some of them may be so obsessive compulsive that they just can't be forced to ship. Fine, they should go get Ph.Ds and do great things in academia, but they're still infinitely more valuable than the people who don't even really grok programming.

holygoat 17y ago
"in terms of ancillary tools, automated testing in general could only be second to version control for what it does to long term productivity." His whole point is that short-term productivity is sometimes more important. No point building a product that'll be easy for you to extend in the future if you don't build it quick enough to have a future.
- dasil003 17y ago
  My whole point is that short-term productivity doesn't need an advocate. If you're literally going to die then sure, go ahead and throw the hail mary. However in the vast majority of cases the future becomes the present quicker than anyone foresaw and then you find out that 20% time savings has now put you in a position where all future development is 50% more expensive, at which point you either (possibly) scored an amazing victory or you (more likely) handed yourself a crippling setback. You know, sort of like the situation that presumably led to the rewrite of Mozilla.
  - The_Lost_Hacker 17y ago
    However in the vast majority of cases Sorry, but that is extremely wrong. In the vast majority of cases, every bit of work you did amounts to nothing. For every successful startup, there are thousands of failures. There is absolutely no point in wasting time on ANYTHING long term until you are sure of success, whether that be attracting a shitload of users or making a shitload of money. I learned this lesson in an extremely painful way.

j_baker 17y ago

Personally, I think the key is in understanding that hacks are fine as long as they're localized. Generally, it's ok to fudge in places. But hacks shouldn't compromise the "big picture".

dkarl 17y ago
hacks are fine as long as they're localized That's the difference between a duct tape programmer and a genius duct tape programmer. The genius has a huge brain that envelopes the entire program. To the genius, everything is local. The non-genius duct tape programmer can't comprehend the entire program, so he just blindly hacks on local problems. When you can't comprehend the whole system at once, you have to use abstraction and good design to ensure that your locally good parts will interact to create a good whole. Compare this quote from Charles Simonyi: Right now, I have to really concentrate and I might even get a headache just trying to imagine something clearly and distinctly with twenty or thirty components. When I was young, I could imagine a castle with twenty rooms with each room having ten different objects in it. I would have no problem. I can't do that anymore. Now I think more in terms of earlier experiences. I see a network of inchoate clouds, instead of the picture-postcard clearness. But I do write better programs.
- j_baker 17y ago
  To take this to an even more absurd level, a true genius duct tape programmer is one who knows that the rest of his team aren't geniuses and programs as such. :-)

sayrer 17y ago

didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?

plinkplonk 17y ago
"didn't netscape get its butt kicked by a bunch of programmers writing multithreaded COM?" In those days, almost everyone writing desktop softare got their butt kicked my programmers writing multi threaded COM who worked at Microsoft, a company that indulged in blatantly illegal or semi legal tactics to do said "butt kicking". Eric Sink recalls how he had an epihpany when he came to know that Micrsoft had 1000 developers working on IE, a product that they gave away. I wouldn't judge programming ability by getting steamrollered by the MS juggernaut.
- DrJokepu 17y ago
  By giving away Internet Explorer free, Microsoft made web browsers a commodity. Before that, commercial users had to buy licences for Netscape Navigator. I think the web greatly benefited from that move.