Joel Spolsky's recent piece on Duct Tape Programmers takes a characteristically extreme position that programmers who get stuff done simply and quickly are wonderful. I say characteristically extreme, because Spolsky has a columnist's approach to writing, i.e. take an extreme position that will get people worked up, although (actually because) it has obvious holes to pick.
I like to say that programmers fall on a Engineer / Hacker Continuum, and that each end has both positive and negative examples. On the engineering end, you have people who like to thoroughly think through what they are doing. The negative version of the engineer is the over-engineering architecture astronaut. They make everything harder than it needs to be. Their first reaction to any change request is that it's probably impossible, and in any case will be difficult and expensive, needing major parts of the system to be refactored, frameworks ripped out, etc.
On the opposite end of the spectrum is the Hacker. Managers love the hacker, because their first reaction to anything is that it'll be easy, and by the time the managers finish discussing whether to do it, the Hacker has already knocked it up. This is Joel's Duct Tape Programmer.
The evil side of the Hacker is that many (not all) of this type of programmer get things done quickly because they don't bother to think everything through, much less test it (Joel's dream programmer thinks unit tests are a luxury). They've coded it up, the code compiles, and they can click through the happy path on their development machine. Ship it! Oh, wait, I forgot to commit my code to the repository. Done, ship it!
Of course this results in bugs, customer complaints, and general disaster, at least if the company has any real customers. It works great for startups, because it gives them something to demo ("we have a working application"), and nobody is using it so the bugs don't matter.
So the positive flipside of the Engineer is that they take care, think things through, and design and build solid applications.
I've worked with Hackers who develop solid, clean, simple code, They're wonderful, they get stuff done quick. I've also worked with Engineers who keep their designs simple and effective. Also wonderful. But more often I've worked with developers who will slide into the negative versions of these if left to their own devices.
A development manager who follows Spolsky's principle of worshipping the Duct Tape Programmer, thinking they're always going to get the positive version of the Hacker work (code that's developed quickly, **and** is solid, fast, and scalable because it's been written simply and cleanly), are eventually going to end up tearing their hair out, not understanding why nobody can get the app to stop crashing, why new features take forever to develop even for their golden Hackers because nobody can untangle the spaghetti (in reality the Hackers end up writing new apps, because it's faster, which creates a new kind of spaghetti).
