That's funny and sadly true in many cases.

But come on, I think we all know what point the article is really trying to make: You can run off and start writing code to some spec in your head; or you can spend a little time upfront finding out what the business needs and users' needs are before hitting the keyboard.

It's not really about putting down "hackers" or lifting up corporate developers. It's about the approach you take when you're building an application that solves a given business or user problem.

When you're writing code for someone else, it makes sense to ask questions, lest you create something that doesn't actually meet the person's needs. When you're experimenting or just writing code for yourself, by all means just hacking away sometimes makes the most sense.

Or he spends the next year producing design document after design document, always being sure to fully discuss the implications of each new requirement, but never writing any code.

Further, his code contains at least one example of each and every pattern described by the GoF.

I see your point, but that's a bit extreme.

The example in the article is obviously stretched, but getting feedback on your work isn't always a bad idea. Getting feedback from users, other hackers, or from business people can help you understand what your customers want. I'm not saying you should always follow their advice, but you should definitely listen and make your own decision. If you're at a small startup where you don't have business people, listen to your users instead.

Stretched? It's stretched like a slinky that doesn't slink any more. It's a lame article with a false dichotomy, as others have pointed out.

Three years?! If this company is truly ruled by such trite examples he would be CTO by then.

Actually UML is the only programming language allowed, so he had to code it all up in the proprietary CASE tool first and then generate the Java from that.

And he actually enjoys his job!