

Put down the abstract factory and get something done - jconley
http://jdconley.com/blog/archive/2009/01/26/put-down-the-abstract-factory-and-get-something-done.aspx

======
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.

~~~
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? :)

------
brl
This is a terrible attitude. If you don't write maintainable code then the
price you pay for it later is that your project eventually ends up permanently
stuck in the mud.

There is a line that you can cross where no amount of refactoring will rescue
you from the mountain of technical debt you've accumulated. Once you're on the
other side of that line, your project is 'bankrupt' and other than putting out
fires you're never going to get anything done ever again.

