Duct tape is a great metaphor. Duct tape was one of my favorite toys as a child. My dad was always mad at me for wasting it. But i can't help it if i want to build a tower from straws and duct tape, a tool thats as flexible as duct tape is empowering for a 10 year old. I propose duct tape become the new hacker symbol! :D
The Duct Tape Programmer
21–30 of 123 posts
Re: The Duct Tape Programmer
#22I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work. Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial rele…
I don't think that's the point Joel is making. At the end of the article, it really comes together. Perhaps you are too heavily focused on the specifics (unit testing, etc) instead of the overall theme. He's basically saying that while the other guys are wasting time overengineering a project, sometimes just getting to work and getting started is a much more productive approach.
Joel isn't directly bad-mouthing unit testing or multithreading, but as developers we tend to think about all of these cool toys we can use and "ooooh" and "ahhhh" instead of actually shipping code. Try not to get so hung up on the specifics.
Re: The Duct Tape Programmer
#23You 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 and complex systems.
Did those systems start out that way? Maybe not, but after a few years and a couple rewrites I'm sure they came to the same conclusion that most programmers do when they work on things for a long time: "I wish I could go back and write some tests / automate some stuff / add better debugging, etc." I know I always feel that way. I do now, after about a year and a half of hacking together our site. I'd kill for a decent test suite and fully-automated deployment. Kill!
Both styles of programming have a purpose. Maybe we'd like to avoid multi-threaded architectures, but it isn't always possible. When you have 6 weeks to launch, maybe unit tests aren't necessary, but eventually not having them will start doing more harm than good.
The more I read the writings of celebrity programmers / entrepreneurs, the more I come to realize that most of what they write reads like an attempt to justify their way of thinking as being The Right Way. Why can't we all just agree there is more than one way to skin a cat and each probably has an applicable use case or two?
Re: The Duct Tape Programmer
#24Awesome read. I couldn't agree more. I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'... While I think eventually one would refine their product so that it uses best practices I would say that having custo…
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!
Re: The Duct Tape Programmer
#25You 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.
Re: The Duct Tape Programmer
#26"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
#27Earlier quoted context omitted.
The Kolmogorov complexity of COM is, at the very least, hundreds of kilobytes of itchy, fidgety, sensitive, and complicated code. The Kolmogorov complexity of xor'ing two pointers to save 32 bits is on the order of tens or hundreds of bytes. (I'm using the term a bit loosely, obviously, but I think it gets the point across.) I suppose it depends on the limit of "slightly", but in context I think it's clear we're talk…
I see what you're saying, and I agree. It's not comparable to COM. I think the thing is, articles like this tend to create some idealized programmer that is just a conglomeration of attributes the author likes even if they are mutually exclusive . To me, avoiding complexity and doing bit manipulation are mutually exclusive. It's like saying you should use left shift (or is it right...?) instead of diving by 2. Ok, it…
Unit tests have sometimes been a great help, especially for regression tests, but they can get in the way, especially if you actually want to ship.
I can see the benefits of getting the 1.0 to market first (if buggy), getting some market share and using that lead time to either iron out the bugs or to rewrite so you don't have to put up with duct tape maintenance.
I've been in a situation where the users started using the prototype because, despite being buggy as hell, it did stuff light years ahead of what they had before. So imo duct tape 1.0 is ok.
Re: The Duct Tape Programmer
#28It'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 off this shtick.
In other words what matters is talent, not duct tape. Untalented duct tape programmers do as much damage as the untalented design-pattern programmers he scourges. So what was the point again?
Re: The Duct Tape Programmer
#29I agree with the basic idea, but I think Joel is going over-the-top with the C++ hate. I've actually shipped real code that used the insanely complicated feature of C++ templates. Works great. The problem is not with a specific language or technology -- it's using the bleeding edge technology, when the boring one will do.
[deleted]
Re: The Duct Tape Programmer
#30[deleted]