Joel Spolsky Has an Interesting Idea of Duct Tape

Joel's recent post reveals a strange notion of what a "duct tape programmer" is.

His first description is of someone who uses C++ templates and multiple inheritance to describe has-a or does-a relationships--someone who knows just enough about inheritance to see how type inheritance can save time, but not enough about contracts to foresee the brokenness of this design. He then goes to a design patterns meeting. I am glad he is going to a design patterns meeting to learn about object composition, and all that's wrong with this lazy, hacky implement-via-inheritance antipattern. I say this template-abuser is a duct tape programmer. Mr. Spolsky calls this kind of programmer an astronaught, and says the duct tape programmer does _not_ hack in this way.

Next, Mr. Spolsky says, "You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us."

Multiple inheritance per se is simple; the complexity is in actually using it. Templates (in general) are the mainstay of the copy-and-paste abuser--the extremist duct tape programmer--but I think Joel is speaking here of C++ templates. A practical and effective programmer will make effective and proper use of generics (assuming static typing is also being used). Therefore, even with all their problems, C++ templates are a necessary part of good C++ programming if you insist on using C++ to begin with. Who would use COM for anything other than working with legacy code? Multithreading is a fact of life sometimes, but should not be used for performance alone without sufficient reason. What "faddish programming craziness" do practical programmers "sheepishly go along with"? No answer to this question is explicitly given in the original article, but Joel does proceed to tear about ideas that have passed into common usage.

Finally, the portrays unit tests as an enemy to releasing on time. First he quotes Zawinsky, saying unit tests "sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that." Then he says "we’ll forgive [duct tape programmers] if they never write a unit test."

Technically, you can ship without unit tests. There are 2 alternatives:
1. Don't test. This way, when you accidentally encounter a bug, it is harder to find the source. Also, you risk the customer complaining about bugs that are shipped. Worse yet, you spend all that time to build a piece of crap. Such a waste of time is both immoral and unfulfilling.
2. Test manually. The disadvantages here are more time spent testing (not less!) and having a harder time finding bugs.

Skipping unit tests is like using duct tape. Using unit tests is _wise_.