Comments for How much is too much? (http://www.insideria.com/2009/06/how-much-is-too-much.html)

How much is too much?

2009-06-11T21:57:51Z

"Amy, every sketch doesn't have to be the Sistine Chapel."

Brent Funderburk, 1991

Brent Funderburk was my favorite professor when I was at Mississippi State, and the reason I switched from being an architecture major to being an art major. One thing that was characteristic of all his classes (and his work) was meticulous attention to detail—seeing the "shadows within the shadow," building colors in layer after layer, and not ever, ever taking the easy way out. So when he told me this at my sohpmore review, I didn't quite know how to react.

And so it began: the balancing act between my inherent desire to do things completely right and the need to just get the work out. I often find myself in hot water because I seem to be constitutionally unable to throw code together that just gets something working today that will have to be revisited and revisited because it wasn't built originally with an eye to making future changes quick and painless.

I think this tug-of-war is made more difficult by the fact that it can be much easier to show progress on something that's just thrown together than on something where several different pieces of code must interact like cogs in a machine before anything works. Additionally, sometimes best practice does take longer than just slapping it together. So it might look as if there's no progress for a while, which can be very frustrating for an employer or client, epecially one who doesn't keep any metrics on how much a given piece of code takes to maintain after it's written.

On the other side of the equation, we have the experts gleefully sharing the latest best practices, most of which seem to take much longer than whatever I'm doing today. I can see the long-term advantages of many of these techniques, but often I have to balance that with the risk involved with not knowing how long it will take me to incorporate those techniques into something that needs to be out now. And then there's my bent toward finding solutions that streamline the tasks I find myself doing over and over—I know that the time spent in research will pay for itself in spades, if I manage to survive the fact that it made this task take longer.

So I often find myself settling for "good enough," while at the same time catching heck for not settling quite enough. I'm not sure what the answer is. What do you think?

Comment from Sven on 2009-06-12

2009-06-12T11:04:26Z

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.

Comment from Amy Blankenship on 2009-06-12

2009-06-12T12:49:42Z

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.

Comment from Travis Almand on 2009-06-12

2009-06-12T14:08:37Z

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.

Comment from Steve Howard on 2009-06-12

2009-06-12T19:48:53Z

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.

Comment from Mark on 2009-06-12

2009-06-12T20:09:01Z

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

Comment from Amy Blankenship on 2009-06-12

2009-06-12T23:07:45Z

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.

Comment from Doug on 2009-06-13

2009-06-13T13:48:29Z

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.

Comment from PKR bonus on 2009-07-17

2009-07-18T01:09:31Z

Hi Amy,

It seems
you raised the right question :)
Claire

Comment from JJ on 2009-08-14

2009-08-14T23:52:51Z

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

Comment from Ryan on 2009-08-21

2009-08-21T22:43:15Z

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.

Comment from black hattitude on 2009-09-08

2009-09-08T08:16:30Z

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

Comment from James on 2009-09-18

2009-09-19T02:38:00Z

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.