Why "Good Enough" Is Good Enough

[Thorin]

Interesting article talking about the "Good Enough" factor in our technology these days: http://www.businessweek.com/print/magazine/content/07_36/b4048048.htm?chan=gl

[Mr. Analog]

My trouble with this mode of thought is that it really isn't forward looking. I mean it assumes that everything is throwaway. Working for almost 10 years I now know better (even as a Consultant) nothing ever gets truly thrown out.

It's better to do it right the first time, especially as the complexity of a system increases.

[Thorin]

It's better to do it right the first time, especially as the complexity of a system increases.

The point the article was making is that the cost of doing it right the first time supposedly stifles innovation.  I've heard more than once at work that I need to balance perfection with cost, and that a "good enough" balance needs to be found.  I heartily agree with you that it saves us all a lot of headaches if we refuse to accept "good enough" technology.  So long as we don't complain about why they haven't adopted flying cars yet (would you really want that to be "good enough"?)

[Mr. Analog]

I look at the project you are working on right now and from a management perspective they have no problems cutting corners to meet deadlines that have already been agreed to. Would that project even exist if it was estimated to take us longer than what the client wants to hear? A better question is; is that something we want to painfully maintain over the years? Not without much wailing and gnashing of teeth, but management doesn't maintain the application and they don't care really unless the cost of maintenance @%&#s with their bottom line.

Likewise a solid delivery doesn't always have to be a hand crafted customized solution. It could be a set of standalone products used to get the job done, or you might have pre-existing components that already do the jobs you need, in which case, why recode the wheel? Take what works and integrate it into what your current needs are. If the pieces don't fit or are too tightly coupled to the task they were designed for you have a chance to develop something that works for your solution. And if you are going to go down that route, you really want to deliver something that does the job and is maintainable. I think the important thing is to remember the scope of the project and really get into the analysis of how to deliver that scope.

Often, we programmers get stuck between making the decision between quality, deliverables and deadlines. If we've got the chance, in my opinion, quality should be our number one concern even if it isn't the best solution financially speaking.

[Darren Dirt]

yup... the good ol' 2-out-of-3 development triangle...

.............................
..PRICE...............SPEED..
....\--------------------/...
.....\................../....
......\................/.....
.......\............../......
........\............/.......
.........\........../........
..........\......../.........
...........\....../..........
............\..../...........
.............\../............
..............\/.............
............QUALITY..........
.............................

Please pick the 2 you want; the 3rd you will not get.