Live data from Hacker News

The Duct Tape Programmer

joelonsoftware.com

51–60 of 123 posts

Re: The Duct Tape Programmer

#51
post #28

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…

The point was that he exercised for 60 minutes today, instead of 30.

Re: The Duct Tape Programmer

#52
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.

Re: The Duct Tape Programmer

#53
post #28

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…

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.

Re: The Duct Tape Programmer

#54
post #43

Earlier quoted context omitted.

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!

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.

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.

Re: The Duct Tape Programmer

#55
post #25

Earlier quoted context omitted.

"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.

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!

So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were more necessary then.

Re: The Duct Tape Programmer

#56
post #49
post #48

Earlier quoted context omitted.

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

Google only uses GWT for their internal projects. Gmail's UI doesn't use it. You're right, though, it's not that crazy of an idea.

Isn't GWT used to build their wave client?

Re: The Duct Tape Programmer

#57
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?

Re: The Duct Tape Programmer

#58
post #25
post #23

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…

"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.

That's a bad conclusion to make: it's the classic tradeoff between importance and urgency. If you only ever do the urgent stuff, the hair-on-fire-has-to-be-done-yesterday stuff, you'll never make time to get to long-term strategic projects.

The payoff for something like unit testing, automated deployment, and continuous integration are over the very, very long haul. If your cost/benefit analysis is always looking at 3- or 6-months out, it'll never seem like a win.

So if you only ever do the urgent stuff and never anything strategic, 3 years later you'll realize that if you'd just sucked it up back at the start and done that stuff, even if meant putting off otherwise urgent features, you'd be further ahead than you are now, because it would have more than made up for the initial investment.

So it's not that you don't do those things because they're not important, but rather because they're never urgent, and because most people's time horizons, especially in a startup, are fairly short.

Re: The Duct Tape Programmer

#59
post #13

"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 After he jumped that shark I don't read anything he writes anymore.

But you've just confirmed the article here. Wasabi is exactly the duct tape he is talking about. FogBugz started as VBScript project, and when they needed to ship it for both Windows and Unix, instead of rewriting the system in two languages, they created a "compiler" to generate PHP code from existing code base. Later they added generation of .NET bytecode, and -- boom! -- instead of rewriting the whole FogBugz project they made it run on .NET runtime.

Wasabi is a duct tape.

Re: The Duct Tape Programmer

#60
post #55

Earlier quoted context omitted.

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!

So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were more necessary then.

So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were necessary at the time.

Might have been better spent. Might have. Say that it was better spent is just begging the question.

That he didn't get the pump can be blamed as much on poor risk mitigation as it can be on avoiding unnecessary expenses. Having a cavalier and dismissive attitude toward mitigating future risks can result in a demonstration of exactly how faulty one's prioritizations really were.

Don't fall into the trap of assuming just because things were done out of assumed necessity, they were the right things to do.

Post reply on HN