The Duct Tape Programmer vs. The Test Infected Programmer

Image via Wikipedia

Joel likes JWZ. They both don't care for unit tests. Joel points to JWZ as a guy who ships. You could argue that JWZ was a guy who shipped, and became a burn-out poster child. The Netscape stuff just wasn't good enough to withstand the Microsoft onslaught. If you take JWZ + (Some) Unit Test + (Some) Test Infected Attitude, you really got something. I am happy to compete against coders who religiously avoid writing unit tests, so I am glad there is considerable variation in opinion. So, keep it up, Joel! The Duct Tape Programmer:

"Zawinski didn’t do many unit tests. They “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.”

Image via Wikipedia

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. A lot of important code is like that.

...

Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off."

32 bits saved on a linked list? I'm convinced! Duct tape ahoy! OK, what is the alternative?

• Look at the Software Carpentry website: http://software-carpentry.org/
• Look at the automated testing sections.
• Experience automated testing improving product.

• Image via Wikipedia

  Image via Wikipedia
• Become "test infected", and stay away from people who are religious "Test Driven Developing" time-wasters.

[Edited 10/23/09] Found a very cute comment thread on jwz's own website:

It seems to me more like you use foresight and pessimism to avoid getting into situations where you need to demonstrate exceptional programming ability. Absolutely no offense, even by faint praise, intended. ... "Use foresight and pessimism" This needs to become some sort of meme metric. ... The formulation owes something to a pilot's maxim: "a superior pilot uses his superior judgment to avoid having to exercise his superior skill."

This sums up Spolsky's mistake - confounding hard-won pessimism about fruity techniques with making a conscious decision to accrue short term technical debt. [exhaustive definition of technical debt here by Brad Appleton http://bradapp.blogspot.com/2009/06/technical-debt-definition-and-resources.html ] If practically 100% of the value of a piece of code comes from the speed of publishing, and you are skilled enough to take on some technical debt, confident you can pay it back later, by all means, go ahead. Publish the code, and forget the unit-tests and forget test-driven-development. But only if you earned that confidence. Here is an excellent diagram about who can and who cannot make this judgement, by Martin Fowler: http://martinfowler.com/bliki/TechnicalDebtQuadrant.html [Edited 10/26/09 ] I found this comment from Reddit by terror406: http://www.reddit.com/r/programming/comments/9nipa/joel_on_software_the_duct_tape_programmer/c0dj2dt

Architecture Astronauts and Duct Tape programmers are fictional characters. There are only competent and incompetent programmers. And competent programmers love and understand elegant architecture, but also know when to go into 'duct tape mode' on order to get the job done and ship the damn product. Edit: There is an easy way to tell the two apart. Ask them about their Technical Debt. A competent programmer will start talking about all the stuff that could have been done better, the incompetent programmer will just give you a blank stare.

Again, the issue is having the skill and judgment to take on short-term technical debt.