[shutter]

The general idea is worthwhile, but not to the extreme the author suggests:

    > Maintainability isn't a factor. Best practices don't
    > matter. Design patterns don't matter. All that matters
    > is getting things done.

Naturally, you must find a happy medium. Go for maintainability and best practices wherever possible, but don't lose sight of your goal: create your product.

That said, the author did acknowledge the need for moderation toward the end. Best practices are thusly named for a reason.

[russell]

He is a bit over the top. Use best practices, but dont create an interface for only one class dont create an abstract class for only one subclass, dont create a data only class where a HashMap will work. All this extra code has to be maintained by someone. In fact the essence of maintainability is to have less code.

[timf]

Agreed.

Another thing the author does not mention is that many of these things you can make very habitual and even into zero cost macros (especially if using a mature IDE).

A habitual extra 15 seconds spent minding something that requires no 'real thought' because you do it all the time can have an enormous long-term organizational impact.

[brl]

Everybody writes shit code when they implement something new to get it working as quickly as possible. What matters is spending an extra 10-30 minutes before checking your code in to turn that sloppy code into a work of art.

It's really that easy.

[timf]

Everyone does that? Then I'm having some kind of Russell's paradox situation with your comment :-)

[brl]

Yes, I mean it's not unusual to take the shortcuts described in the article to produce working code. Even the very best programmers who turn in immaculately maintainable software do not just sit down at their desk and type perfect code into their editor.

First you write a really bad version that mostly works. Then you go back and fix that abomination before anybody else sees it. You don't want everybody else to think you suck at programming, right? :)