For me, "good enough" is, when my code does, what it should and when it is structured in a way, so that i can refactor it later on, when new requirements come in. This is a different approach compared to trying to make your code incorporate future needs. Instead, you design your code with the thought in mind, that you might want to change it later on. If you start designing your applications not with the mindset of possible future needs but with the mindset of being able to change/refactor your code, then you're under less pressure of doing things completely right the first time. We all know, that we never do things right the first time. So we should leave a backdoor open for changing things, when needed.

I think what you've just described is pretty close to what I consider to be exatly the right way, with the caveat that I tend to emphasize the data structure necessary to make changes easy in the future. That does just take more time up front, since if you get the data structure completely wrong, it's almost impossible to go back and fix it once it's in production.

Another factor to consider is the costs involved. Time is money after all. In a somewhat near perfect situation we would have the time to implement things now we can see might be needed in the future. Plus we could follow best practices to make life easier if we have to revisit the code in the future.

Often times the client or boss doesn't want to incur the cost of doing it right the first time. Ok, maybe saying doing it "right" is a bit strong in some cases but you get the idea. Sometimes you have to go against instincts and do good enough for now. The hard part is making the unaware understand why good enough was done in the first place when the criteria pushed the project in that direction. Short term thinkers have a problem understanding an extra thousand or two dollars in the budget now might save them thousands later.

It's like the difference between how the Japanese approach business decisions versus how American's approach them. Long term versus short term.

But I agree, sometimes "good enough" is a necessary but bitter pill to swallow.

Amy knows from long experience that I am way more able than she is to just "make it work". I don't have her skill and patience to research that last little detail for hours.

That's not to say that I don't try to do things 'right' or 'well', but just that I don't have the same burning drive to make it 'perfect'.

Having seen code from a zillion developers over the years I know that it is perfectly possible to build awful code that still gives the customer a working solution - and on the surface, where the users hang out, there is often no obvious difference between good and bad code provided it achieves the all important "does it work?" requirement.

But under the hood is where the difference lies. Some code is not just bad, it's unmaintainable. I always strive for maintainable, regardless of how quick and dirty I might have to be.

I used to be meticulous in doing things "right" until a few years back at a one-day seminar, presented by Colin Moock in NYC on AS3, where he talked about how people get too hung up on over-engineering things and worrying about what other developers are going to think.

That's when it hit me that no other developers ever get to look at my code, and I need to chill when it comes to this stuff.

Now, I take the 'does it work?' litmus test as the right way.

Then again, I feel like I can get away with that because I just learned from the start to always use whitespace, heavy commenting, etc. My worst code is 1000+ times more readable than most of the crap I've come across.

mark
www.elearninglive.com

When I was primarily an Authorware developer, I inherited the code of several developers I'd encountered either in person or electronically over the years, and I am sure others have inherited mine. Now that I work in a large ASP shop with high turnover, it's pretty much a guarantee that others will have to maintain my code.

In a way, it bothers me that code that took me a while to get right (and might have made me look bad in the process) might make someone else look like a star when what's normally a hard change is a five minute job for them. But then again, in some cases I might be the one maintaining my code, and I figure if a 20% extra effort on the front end will save at least 20% on the next pass, it's worth doing. And then there are the things that flat aren't possible to add if the initial design was wrong...

But I really don't care if other people think my solutions are elegant or not--the reason I care about getting it right in the first place is that I've had to go back too many times and add what I decided not to put in the first time and the total time wound up being much higher than what it would have to just get it together the first time.

When you make something really good in art, music, or software the tendency is to try to make something just as good the next time.

However if you go too far too fast you can get overcommited to a particular path and become reluctant to change.

By starting off with few details you can review and reflect and fill in what is really needed. You can make a few to throw away.

Hi Amy,

It seems
you raised the right question :)
Claire

Brent Funderburk sounds familiar to me, I had a professor like that when I was in college.

JJ

Its an interesting battle on doing things right vs getting things done. While coding, I personally try to invest time in interfaces between the components right and then I cut corners while designing a module itself. I work on development of a free web dating site and my team believes in iterations of the code. We code something once and as we develop new features, we keep going back to the old code and keep improving it over time.

Its doesn't generate a perfect codebase but its the best combination I have found personally between getting things done and doing them right.

I think that is too much when other people can't understand you.

LOL.. dont know if Brent was the first person to say that quote... I've heard many people say it. But either way, it's very inspriational. Thanks for sharing.