I wasn't going to respond until I saw supportive tweets such as 'thoughtful, provoking essay'. (Damn you, Twitter, now you've drawn me into this.)
Joel's piece isn't a thoughtful, provoking essay. This one is, but Duct Tape Programmer is just a quick rant. Like I said, I'm a fan of Joel, but let's not be sycophants here!
The Gist
I freely admit that I haven't read the book, Coders At Work, but here is Joel's article. Here's my summary of his points:
- Keep things as simple as possible, but no simpler.
- 'Simple as possible' is context dependent.
- It's the features, stupid.
His other point is that the definition of 'simple as possible' depends on circumstances: the context of a start-up company is much different than a mature app at a large enterprise. Naturally, the start-up will have a much more stringent definition of 'simple as possible'.
Finally, Joel admires those that concentrate on features, and who ship code.
The Surprise
I agree with Joel. His thesis isn't particularly original, but as I see it, it is virtually indisputable.
However, I take issue with some of the details. My point is that this just isn't a thoughtful post.
At Issue: What is Duct Tape?
Joel gives lots of examples of complex technologies: multi-threading, COM, and CORBA. Hard stuff, no doubt. He goes on to write:
... any kind of coding technique that’s even slightly complicated is going to doom your project.
However, against the backdrop of extremely complicated technologies, he doesn't define 'slightly complicated'. There's not even an example! From what I can tell there isn't even an example of duct tape!
Is OO slightly complicated? AOP? Functional programming? Transactions? Languages without garbage collection? with garbage collection? The notion of 'simple' is much more nuanced than Joel implies.
This rhetoric reminds me of the straw-man argument and definitely is the logical fallacy of false alternative. Joel assured me on Twitter that the COM example is real, and not a straw-man. I'm sure it is true (I didn't think Joel was being deceitful), but berating the most extreme case with no comment on the middle-ground does not make a thoughtful article.
At Issue: Design Patterns
Quick -- what is the most commonly used design pattern, using the vocabulary of the seminal work, Design Patterns?
I don't know, but I'd wager that it is the Iterator. In fact, if you work with Java, it is so common that it may not 'count' in your mind. And yet, there it is: a freaking commodity, no less.
Joel takes a shot at a 'Design Patterns meet-up'. It's true that people can go crazy with esoterica, but again, nuances are lost with broad strokes. It is easy to deride the architecture astronauts!
There may well be times when a design pattern is the right fit, and it is our job as professionals to be prepared. True -- we have to be intellectually honest and disciplined -- but that doesn't mean we shouldn't be informed.
At Issue: Unit Tests
Hoo-boy, Joel fired a shot across the bow of the agile ship. A brave man.
I'm a big fan of unit testing and am convinced that they helps us make better software. However, if the context is a start-up in an ultra-competitive space, and we are racing for the '50% good' mark, then I agree that unit tests would slow things down. If I were in that environment, I would shower every 2 hours just to get the smell off me.
The issue here is that most of us are not in that context, and the post implies that unit tests are used for 'endless polishing' to get to the '99% sparkling' mark. That's just bogus.
Unit tests are the first client of any software. They find bugs. They highlight problems in an API. They serve as executable documentation. They get us to the X% mark faster, where X is way higher than 50 and not as obsessive as 99. Most projects are shooting for X.
The Upshot
We all agree that simplicity and features are of paramount importance. We all agree that we shouldn't listen to architecture astronauts with high-falutin', ego-driven schemes that are not appropriate for the situation. As usual, the devil is in the definitions (what is appropriate?).
But to the Twitterverse: just because an excellent writer wrote a piece, it doesn't make it excellent. Call them out, when they have no prose, and write your own 'duct tape post' instead of broad, incendiary brush strokes.
I've never been on a project where the problem was too many unit tests. In fact, I'm almost always on projects where the problem is too few unit tests. I feel like anti testing people describe different worlds to me that I've never been to.
ReplyDeleteDuct tape programing gives you the same thing as duct tape mechanics give you.--
ReplyDelete1)Something may work but you won't really know till it is put into production. The guy with the duct tape usually isn't the guy who is putting everything on the line.
2)When you need to go back and modify it no one really knows what they did, why they did it or how to get it to a state where someone else can work on it.
3) Duct tape is only used when the skills, talent or tools aren't available to do it right in the first place. (no matter how much duct tape was used. Sooner or later a welder will need to fix the frame of the go-kart. )
With that said there is a whole world of programming between decision paralysis and duct tape programming and the article missed it completely. But what do you expect from duct tape.
Using unit testing extensively Does Not Slow Down Anything. I'm also a test-infected programmer and I came to the realization that the time spent to write tests is quickly paid back the first time you have to debug...
ReplyDeleteWhile I have never been on a project with too many unit tests, I have been on lots of projects where every simple change, either in the program or the environment, breaks some tests. That is, there were a large number of brittle unit tests that had to be maintained.
ReplyDeleteTo say that there is not a movement in the blogosphere to push endless polishing is false. It exists and it is not helping us to deliver working software faster.
I wish it were easy to implement and *maintain* products with a good set of unit tests but it is very hard. Arguing around the edges (e.g. how many tests are enough or do they make development faster or slower) seems to me to be a bit of a waste of time.