On the dangers of analogies
Say what you will about Joel Spolsky, one thing he is really good at is starting a discussion. His latest post, "The Duct Tape Programmer" is no exception. In it, Joel discusses Jamie Zawinski (one of the initial developers of Netscape), and uses him as an example of a developer who just gets things done, without relying on the current fashionable "best practices". The discussion on Joel's site gets a little heated (as it often does). Many people seem to be caught up in the analogy, however. Duct tape, while an incredibly useful product, has the reputation of being the first (and likely last) tool of sloppiness. Thirteen seasons of "The Red Green Show" have certainly contributed to that.
The issue is not developers that just slap stuff together and put enough duct tape on it to ensure it holds together. Rather, it is, as Dare Obasanjo adds, "shipping is a feature". What Joel is describing as a Duct Tape programmer is one who spends more time shipping code, rather than spending more time designing code. To reduce confusion (or perhaps to just put my foot in it), I'd like to submit a different analogy for those developers: Journeyman.
While few guilds still use the term, a journeyman was a skilled practitioner in his craft who was allowed to travel, earning his pay. He had completed his apprenticeship - and therefore was skilled - but had not yet completed his "master work". In other words, he could be relied upon to do good work in a reasonable period of time, but it may not be a masterpiece.
I have said many times in the past that the best mark of good code is something that you can pass on to someone else, or come back to after a six month absence, and be productive in. There are many techniques that increase the odds of this (and I do include some things like TDD, OO and even some of the SOLID techniques here), but nothing that guarantees it. If a duct tape (or journeyman) programmer produces reliable code fast, it doesn't matter if they used or didn't use LINQ, or jQuery or had 100% unit test coverage. The customer is completely unaware of any of that. They care if it works the way they want. Other programmers shouldn't care either. What they should care about is, "can I read, maintain and extend this code?" If yes (most of the time), the programmer that wrote it was a "good" programmer.
Analogies are powerful tools, but sometimes, they mean different things to different people, and those differences can actually confuse the issue. Sometimes, you just need to actually read the message, rather than relying on your reaction to the analogy.