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.
The Duct Tape Programmer
81–90 of 123 posts
Re: The Duct Tape Programmer
#82Over 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
#83Earlier 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…
Re: The Duct Tape Programmer
#84Earlier 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.
Re: The Duct Tape Programmer
#85It'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…
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
#86EDIT: The fact that a complete rewrite is a big mistake, is another story, of course...
Re: The Duct Tape Programmer
#87Earlier 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.
Re: The Duct Tape Programmer
#88"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?
Re: The Duct Tape Programmer
#89Joel 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…
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
#90I 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.