Live data from Hacker News

The Duct Tape Programmer

joelonsoftware.com

81–90 of 123 posts

Re: The Duct Tape Programmer

#81
I have friend like that and he saved my ass many times. When I was stuck trying to find satisfying solution, he was almost always coming up on the spot with something simpler then I was striving for, but upon close inspection good enough. If I pointed significant problem in his solution he either came up with fix or abandoned his idea without regret.

I like to think that I design better apis and libraries than him because I concentrate much more on what I want to have and try to weed out any inconvenience, but when I can't get what I want then he comes up with the idea I actually can get and is good enough.

Re: The Duct Tape Programmer

#82
Joel does not mention that Netscape code was so bad that it cost them serious credibility and customers. As a Netscape user back in the day, I did not care whether Netscape used unittests or duct tape, but I switched from Netscape to Internet Explorer because Netscape was so buggy it was painful.

Over a few years Netscape code became so unmaintainable they had to start from scratch, which cost them years. Joel wrote in another famous article that this was a major mistake. However, if the code is a giant "pragmatic" mess with no architecture and no unittests, it becomes extremely hard and dangerous to refactor.

IE also got a lot of mindshare among developers because it actually tried to implement some standards like CSS, which Netscape completely disregarded. Netscapes "pragmatic" alternative to CSS, , and so on luckily died together with Netscape.

Many developers started making IE-only pages because it was almost impossible to get anything to work in Netscape 4. IE6 is pretty unpopular among developers today, but this is nothing compared to how the Netscape 4 generation was reviled back in the day by anyone having to develop for it.

> Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. They thought that they only had a few months before someone else came along and ate their lunch

Also remember that they lost it all, and someone did eat their lunch. So maybe the their strategy should be reexamined?

Re: The Duct Tape Programmer

#83
post #62
post #60

Earlier quoted context omitted.

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…

Fair point with the motor pump, but it seems to me that we end up on square one: it might have been better to get the pump in advance, or it might not have been better. It all depends. With the motor pump example it sounds like a no-brainer, but even there it depends. If you have a very small boat, heaving a motor pump on board might actually sink the ship. There are all sorts of risks, and it isn't obvious when it i…

This is where experience and wisdom are supposed to come in.

Re: The Duct Tape Programmer

#84
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 always, always, always better to have a delay in version 2.0 than that a delay in version 1.0.

Re: The Duct Tape Programmer

#85
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…

I got pulled up short by that ending too.

Most of the piece seems to be about the benefits of keeping it simple and doing the obvious thing that will work rather than outsmarting yourself. All well and good advice, easily applicable by anyone with the confidence to face down blowhards that would rather things feed their leet-programmer ego than actually meet a customer's need.

But then it goes into not writing tests and doing complicated bit-munging to save a bit of time or space (both of which you think would be the opposite of the previous advice of keep it simple and accept your own human failings) and which is stuff that you can only get away with if you are both talented and lucky.

If he dropped the last paragraph and the bit about not writing unit tests (which, the theory goes, will save you time assuming, again, that you're not a lucky genius) then this would hold together somewhat coherently.

Re: The Duct Tape Programmer

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

EDIT: The fact that a complete rewrite is a big mistake, is another story, of course...

Re: The Duct Tape Programmer

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

But all that refactoring will be easy because of the comprehensive unit test suit you wrote. Oh wait...

Re: The Duct Tape Programmer

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

"After he jumped that shark I don't read anything he writes anymore." ...how'd you get that quote then? Or did you only read enough to get something to complain about?

I got it from another posting right before mine. I'm sorry I offended you and your beloved coding sensei.

Re: The Duct Tape Programmer

#89
post #82

Joel does not mention that Netscape code was so bad that it cost them serious credibility and customers. As a Netscape user back in the day, I did not care whether Netscape used unittests or duct tape, but I switched from Netscape to Internet Explorer because Netscape was so buggy it was painful. Over a few years Netscape code became so unmaintainable they had to start from scratch, which cost them years. Joel wrote…

The argument ingnores a fact that if netscape did not take off and be popular, microsoft might not ever consider buying spyglass browser and expanded it into IE (Eric Sink led the spyglass team, with his memoir http://www.ericsink.com/Browser_Wars.html) and waged browser war in late 90s.

What all software architects forget is, most of time, the piece of code that we wrote is to solve problems in life. Those problems have their life cycles; some are long, some are short. While we seems like to imagine the piece that we wrote will be a masterpiece as a Cathedral/Pyramid and last for 1000 years. Unfortunately that is not the case. Most of time, our programs are just solutions among solutions to a series of bootstrapping problems. So unless we have a lousy but popular solution to a problem, our potential competitors might just ignored a market and no progress happened for the field. And this is a lost to human progress.

It is the same as maintaining old buildings, if condition is right, you may just tear it down and rebuild what you deem is fit by today's standard. But don't forget the original building has served its purpose.

Edit:

I personally have affection for Netscape 1.0. I still remembered how people in my lab in Taipei ftped to netscape's download server and waited for the moment when they uploaded the tgz file and started to download it and installed it on Sun workstations. And by using it I felt making stuffs on internet is better than studying physics and the decision changed my life.

Re: The Duct Tape Programmer

#90
I would just say this for folks who don't like unit tests because it takes longer. Push yourself away from the keyboard and think about it. When one writes codes one writes unit tests in ones head or the code doesn't work. I submit that we always write unit tests. The difference is in one case we keep it so we can run it over and over, in the other case we do it anyway in our heads then throw it away. I am not convinced that writing unit tests now takes any longer. We all know it saves our bacon later.

I have personally thrown out entire chunks of code except the unit tests and started from scratch to get things working again. I don't think the value of this can be understated.

Post reply on HN