Duct tape programmers
Sometimes I read something and I just know that responding off the cuff would be a big mistake. Joel’s latest essay, duct tape programmers, is one such case.
I many ways, I feel that this and this says it all:
Sometimes I feel like Joel is on a quest to eradicate good design practices.
Let us start from where I do agree with him. Yes, some people have a tendency to overcomplicate things and code themselves into a corner. Yes, you should keep an eye on your deadlines and deliver.
But to go from there to disparage good practices? To actually encourage brute force hacking?
I think that Joel’s dream developer is the guy that keep copy/pasting stuff he finds on the web until it looks like it is working. At the very least, it will make sure that his bug tracking system is used.
And the examples that he gives?
Here’s what Zawinski says about Netscape: “It was decisions like not using C++ and not using threads that made us ship the product on time.”
Oh, wait, let me see. Netscape is the company that:
- Routinely shipped a browser that kept crashing
- Wasn’t able to compete with IE
- Got their source code into a bad enough shape that they had to rewrite it from scratch and lose 5 – 6 YEARS doing so
- Collapsed
Yep, sounds like this duct tape notion really worked out for them, no?
Here is the deal, every tool and approach can be overused.
But that is part of being a professional, you have to how to balance things. I am not sure what bee got in Joel’s bonnet, but it sure seems to cause him to have a knee jerk reaction whenever good design principles are discussed.
Shipping software is easy, you can cobble together something that sort of works and you have a shipping product. People will even buy it from you. All you have to do is look around and see it.
The hard part is to keep releasing software, and with duct tape, your software will be taken away from you by software protective services.
Don’t, just don’t.
Comments
Thank god, after reading a lot of the responses in the blogosphere I was beginning to think I was the only one who disagreed with the duct tape philosophy.
While I agree with your response to Joel's article and his thoughts on practices, I think the Netscape case that Joel used as an example is misrepresented, and an overall poor example by Joel. Particularly interesting is Jamie Zawinski's response: http://jwz.livejournal.com/1096593.html
Dunno, maybe he had a recent stint working for Government... :D They substitute Duct Tape with Process-Driven Red Tape.
I think you pretty clearly missed the point of Joel's article. He wasn't encouraging 'brute force hacking.'
"I think that Joel’s dream developer is the guy that keep copy/pasting stuff he finds on the web until it looks like it is working."
Um, no. Totally wrong. Re-read it, that's far from what he was saying.
@jdn: That's the problem with Joel's duct tape text, it's so incoherent and illogical on some points you just cannot be sure what he actually means.
I picked up the book that the interview comes from. The way it is explained in the interview, the massive rewrite of Netscape came after they acquired another company. And this other company kind of took over the Netscape engineering process.
So the rewrite was all Windows, Windows, Windows and port to others later, which will lead to sub-par implementations on other platforms. They went for a very pure, OO design that was overly complicated.
To me the first few versions were actually really good (compared to Mosaic, IE 1 and 2).
And the decision to not use C++ and threads? I'd have made (and did make) the same one back then. C++ compilers were horribly inconsistent. They had different features on different platforms (i.e. something that compiled on GCC may or may not compile on Visual C++ at the time - GCC had exceptions, VC++ used setjmp and longjump which sometimes didn't clean up the stack properly. Using VC++ 1.52c or 1.52d huge difference a letter makes). C was a very well defined standard with stable compilers. Let's also not forget this was the era of Win16 and Windows 95, Mac OS 8 and 9. Not exactly the cutting edge OSes we have now. Cooperative multitasking was still more popular than preemptive.
I know this post is more about Joel than the "Duct Tape Programmer", but just a little history.
This article is shit, thank you.
@LKRaider
There is nothing remotely illogical or incoherent about Joel's post.
"I think that Joel’s dream developer is the guy that keep copy/pasting stuff he finds on the web until it looks like it is working"
Far from it, I read Joel's article as a tribute to the guys who go out get things done, who do the grunt duct tape work so that others don't feel the pain.
For me duct tape programmers are the guys who get down to the metal and actually write stuff like dynamic proxy, or rhino mocks so that the rest of us guys can preach benefits of TDD, IOC all day long.
An example of duct tape v/s architect astronaut I find in the evolution of Perl (the duct tape of the Internet) where Larry Wall single- handedly went and implemented his vision in Perl 5. You name it, you got it - local variables, OOP, closures, lambdas and only God knows what else.
Perl 6 was supposed to be the next big thing, with it's own Utopian VM, redesigned with "solid design principles" from the ground up and guess what? I've been waiting for over 6 years to try it out ( www.perlfoundation.org/.../index.cgi)
Overdesign sadly has become a norm rather than an exception, and feel the pattern architecture guys are to blame, so are the TDD salesmen with overly simplistic "stack push/pop" examples.
Having tests works wonders for regression, good design you learn from experience.
Ajai
I don't know if it is right or fair to use statements like
"...It was decisions like not using C++ and not using threads..."
in this context. The mentioned decision was surely right at that time. I remember how we build an cross plattform C++ ORM in those days and I know how hard it was to find a "code consens", that satisfies all the different C++ compilers available. From todays point of view, many people might not understand these problems...
Looking at todays .NET world it is surely a different thing. I think it is always good to try and use new technologies or approaches but one should not forget the mediocre programmers and theire ability to understand and use those things. And if you follow the blogs and threads out there you have to admit, that there are often tendencies to overcomplicate things, just for the reason of a possibly better design. This leads to the problem with the elitist programmer you wrote about some weeks ago, since there are many programmers who are not able to follow and on the other hand some of the authors are not willing to explain it in a understandable way. The nHibernate or castle mailing lists are sometimes good examples for it...
I've been working with many kinds of developers and have also met too ambitious ones, knowing design patterns, software architecture and trying to apply all their knowledge to basic tasks. Results were horrible, code incomprehensible and they used way too much external tools & libraries. I'd really prefer duct tape in such cases. Many software projects I have been working on have either finished their lifecycle, became obsolete and replaced by other tools or were rewritten because of changing technologies and requirements. Something that was a pearl of design 10 years ago now looks quite messy - it doesn't matter anymore if it was duct tape or something better.
Attacking people doesn't serve you well, young padawan.
Be careful of the Dark side.
To be sure you're actually know what you're talking about. Have you ever used Netscape 2.x ?
Older,
Yes, I did.
There is a reason that I talked about the later versions.
It is the result of this duct tape that I care about.
You missed what a 'duct tape programmer' means in the context of joel's article. He didn't mean some hacker who hacks in 2 lines of utterly crap to work around a bug instead of fixing it properly. He meant a person who is practical and applies what works instead of redesigning the complete architecture, ordering a rewrite and spending years of development to arrive at the same spot.
In that light, the term 'duct tape' is badly chosen, I think, as it does suggest a hacker who adds two lines of cruft to work around a lame problem.
So, you and I, we're the duct tapers in joels article, as we get things done over and over again. We solve stuff the way it works. Are we 2-liner hackers who have no clue what's going on? No. Are we architecture astronauts? No.
Funny thing is that I read that interview from the book. Maybe it was misinterpretation, but it seemed that Jamie Zawinski hardly got anything done while he was a programmer. He moved from one soon-to-be burn out project to another and had most of the time nothing to do than tinker with the stuff he choose/like. I may be ignorant really about his contribution, but the book really minified it.
My experience differs, for many teams (all too many) shipping software is incredibly hard ... one of the accepted wisdoms of software development is "all projects are late and over budget"
Shipping is very hard for most development teams, in either a "high quality" or a "low quality" state ... obviously shipping with higher quality is better, but not shipping at all is very bad.
Well, there are some tidbits of interesting value in Joel's rants, but most of the time his articles are self-serving pieces explaining why he bases his flagship product on a homebrew version of vbscript.
Where Spolsky goes from slightly annoying to entirely bizarre is when he tries to soungf like a bleeding edge geek and warns about the evils of multithreaded COM and CORBA IDL hell. Right, thanks for the piece of advice Joel, next time I'm stuck in a temporal loop and am forced to code in 1993, I'm sure to remember your piece of advice.
Basically, Spolsky is the MS-centric version of Paul Graham. He rarely makes sense, he did achieve something of value aeons ago (some proto VBA for Spolsky, some E-Commerce App everyone forgot about for Graham), thinks it's an entitlement to spew nonsense thirty/ten years later (painters and hackers, duct tape programmer, yeah right) and like Graham, for some really really non obvious reasons, he's still seen as someone whose opinions we should consider.
Well said.
thank you Oren for clearly stating what had had to be said about this new nonsense from Joel.
we should just remember: tanks and cars are not (only) made of duct tape ;-)
Thanks..
I read the initial joel article and I somehow stumbled across a few agreeing responses and I just couldn't resist the feeling of being creeped out by what he was saying.
Well said..
I think Joel brought all this on himself with the term "duct tape programmer". It's a complete misnomer.
Joel needed to think a little harder about what kind of language he wanted to use before he wrote that title. He's got a wide readership.
I've called him a wind bag a few times. Then I took some of it back when I read one of his books. But on balance he is still a pretty strong gust of hot air. I do give him credit for being a good marketer. But that doesnt make him a tech guru of any sort. Just someone similar to Michael Moore in the dev world.
@Yann: Love you man! Exactly my view on things.
"Paul Graham is a funny guy. From one point in history, where he wrote an unmaintainable (they had to drop it) and unsuccessfull (Amazon has beaten them) piece of software which he sold to someone clueless (Yahoo will go down in flames) with too much money (they again buy companies without clue), he extrapolates (from this random event) his view to the whole craft of software development. Funny to read, but pointless. "
http://codemonkeyism.com/paul-graham/
@Stephan and others
I don't really get why you get so infuriated about Spolsky's views, is pragmatic approach so eccentric and old-fashioned? It's rather obvious that customers aren't paying for unit tests, TDD, DDD, and whatever acronym you come with, and what's unpaid for will also be unmantained and fall apart sooner or later.
And regarding Ayende's remarks about Netscape's failure - I don't think they failed because first version of Netscape browser was a duct tape crap, they failed because they decided to rewrite it and make a perfect product... So probably they started with TDD and design patterns and before they decided on the project management methodology and code structure five years have passed and they were out of market...
@jdn,
I do believe that his post could be read in many ways, just because you see it one way, doesn't mean everyone will see it in the same manner.
I'm down the middle of the road with it, he makes some good points like about Astronaut Architects who want to over engineer something just so they can use the latest and greatest technologies, or even worse, because we "have to" since it's "old" (or done in the "old way"). I see many people in the ALT.NET community becoming this way.
On the other hand, the just ship it attitude doesn't always apply to things. Joel's statement that if it ships and is only 50% functional, that's still 100% more functional than something that didn't ship is completely flawed. Sure, that's great for getting out a Free Dating website, or even StackOverFlow.com, but try that with something like financial software, or software that you pay to submit to regulators and you rapidly see how it's a bad idea to ship incomplete, broken code.
It's hard to disagree with the critical reaction to Joel's comments. I find it difficult to take his advice when it comes to development practices.
One thing to point out though is that he has done a really good job promoting the idea of giving your developers the best environment possible to work in. For that he does deserve credit. This isn't to say that the criticism is unwarranted or shouldn't be spoken but I think it's fair to point this out while he's taking some (justified) heat.
I started to reply here but it turned out to be a bit longer than is prudent for comments...so here it is azurecoding.net/.../...a-duct-tape-programmer.aspx
Spolsky is a blowhard marketeer, who appeals to the unsophisticated. Sure Joel, there are only developers who know all the most modern software engineering techniques who don't have the ability to understand when or how to apply them. We are in fact so dumb, we measure success by number of design patterns implemented per line of code.
From everything I have read of Spolsky's, what stands out is that he is not relevant.
Doing Duct tape programming just to meet the deadlines could get you in trouble if it doesn't pass the code review. When your part is delivered for review before it goes to the client or into production it needs to meet certain explicit and implicit criteria or you'll be expected to improve it. Explaining that you needed to "duct tape" to meet their unreasonable deadline might piss them off... Just do it right the first time unless the boss asks you to "Go MacGyver on that shit."
"From everything I have read of Spolsky's, what stands out is that he is not relevant. "
People who aren't relevant can make remarks all they want and no-one who give a ****. Joel on the other hand, can write whatever he wants and a lot of people are suddenly very upset. That doesn't match with 'not relevant' at all, on the contrary.
Also, Joel happens to co-run one of the more successful development sites out there, if not one of the most successful ones at the moment.
That doesn't mean he's right when he makes a remark, that's a different story. But saying he's irrelevant is silly. Or stupid. Or both.
I also picked up the book. It's actually quite boring, but totally worth it. The article in question references jmz and his situation at netscape. Couple of responses to your points:
The time frame of jmz contributions discussed in the book is NS3, specifically NS3 Mail. As far as I remember NS3 mail was rock solid and ushered in the 3 pane mail interface. The piece that sucked (in jmz's estimation) was NS4 which was driven by Collabra folks and which was written in c++.
The history is well known - it played out in courts. Not all Netscape's fault. Kind of hard to compete against free.
Again, the NS4 code, which was different than the NS3 codebase.
I'd say pick up the book, it's worth it just for this one interview.
Comment preview