Is anything ever good enough?

The last time that my wife baked banana bread, as I was tasting it and thinking about the flavor, I said “what if you cut-back the butter by one third and substituted applesauce instead?”  I thought it was a cool idea, but she took it as criticism and got a little irate, “Is anything ever good enough for you?  Can’t you just try to enjoy it and leave things the way they are?”

At that point, the correct response was supposed to be, “I’m sorry dear.  Yes, of course this bread is very delicious, as always.  What was I thinking?” but, since I was already deep in thought and my mind was in an analytical state, I was tantalized by her (probably rhetorical) question: Is anything ever good enough?  Is it?  Can it be?

Criteria for “Right”

As a programmer, I take my job very seriously.  I feel an obligation to do my job in the best way that I possibly can.  That usually feels like a moving target, because one man’s treasure is another man’s trash.  Putting that aside though, there are some things in the programming community that are considered “good” things/practices/techniques and “bad”.

Let’s just imagine, if someone were to ever look at my work and say it was sloppy or amateurish.  (Of course it is hard for any informed person to actually think this, but I have a strong imagination.  So, let’s just imagine…). I would probably take it personally.  I don’t think I would get emotional or lash out, “I’m not stupid, you’re stupid!”  That would be unprofessional.  Instead, I would take it to heart.  I would HAVE to know what could be done to make it pure and “correct”.  It would bug me until I got to the bottom of it.

In spite of this, there have been times in my career, when people have looked over my code, raised an eyebrow and asked, “What is going on here?  Why did you do it that way?”  I didn’t have a good answer.  I was cold-busted.  This is because sometimes, when I have tight timelines and the pressure starts going up a bit, I sometimes yield to the pressure and cut some corners.  I try to determine what will make it “good enough (for now)”.  When that happens, I usually feel a little gross.  A shower doesn’t seem to wash it off.  I need a good night’s rest and a solid breakfast.  Then I go back and make things right.  I refer to this process as “First get it done. Then make it better.”  I make a point of meeting my deadline (so people aren’t waiting because of me) but I don’t just settle for “Good enough”.  I come back to make sure it is “right” and it is something I can be proud-of.  I expect all of my work to be representations of my reputation.  I want it to be “on-time” AND “right”.

I have come across other people’s code that seems to have suffered from the same timeline conditions, except it seems like they never got back to “make it better”.  Considering how much it would bother me, I am usually quite amazed that some people are able to walk away from a mess like it is no big thing.  It would be like they were eating a candy bar and dropped the wrapper on the ground where they were standing and then just walked away without caring.  How do people do that?


This is one of those “craftsmanship” sort of things.  I’ve inherited some projects that were just begging to be refactored.  They practically refactored themselves, while I held onto the keyboard and mouse.  Other times, I have looked at some code and knew it needed to be refactored, but I couldn’t pick an approach that felt right.  I had to ask somebody else if they had any ideas.  It felt weird.

I have had a few blocks of code that just didn’t look right so I refactored them and they looked better, but still not quite right.  So I asked a colleague for a recommendation and it helped but I still wasn’t satisfied.  After realizing how much time I just burned up, I had to snap myself out of it.  I have other things that are more pressing.  This will have to be good enough for now.  I just need to remember to get back and finish refactoring this one. So, I guess you could say it wasn’t  “good enough”, but it was “good enough for now“.  I’ll have to write it down and show it to my wife later-on.

If it ain’t broke, don’t fix it vs. maintainability

I have looked at projects that were beyond refactoring.  It was more like they were begging to put out of their misery.  Those ones will give you nightmares.  It’s as if the code escaped from the movie Hostel.  What kind of madman does things like that to code?

You just stare at the horror and you start thinking about all of the refactoring (hmm, these eighteen goto statements are really just while loops but these twelve are exit conditions).  You calculate the person-hours in your head.  Once the magnitude starts to sink-in, you start wondering if it would just be easier to construct an iron-mask for the code instead of doing reconstructive surgery.

Okay, enough grotesque metaphors.

My point is really this: If the program actually runs and just needs a few tweaks or a minor feature or two, it can be difficult to justify a full overhaul or refactorization.  If you invest 40 hours to save you 5 (over the next 12 months), then you are NOT making a good investment.  Sometimes you just have to stick another piece of gum and more duct tape onto that heap, just like the last dozen people did.  At least it will be consistent.  The program isn’t “good enough”, but from a business ($) perspective, it is good enough for now.

On the other hand, if the app is so messy that only Brian Kernighan is smart enough to maintain it, then 40 hours of refactoring might save your company several hundred-thousand dollars, this month.  The key difference is a realistic assessment of cost to fix it vs. cost to maintain it.

Too many right/wrong answers

I have also seen really big/complex systems where there really is no “right answer”.  The technology does not yet exist, to make them work well, with little (or no) user interaction (for example: BCBS’s receivables.  That is pretty big).  So instead, you need to piece together a few systems or components to satisfy the current need.  Architecting a large system like that, is always nerve-wracking, because you always suspect that some new technology might be around the corner that will obsolete everything that you have just done and make you look foolish.

So, I feel like I have adequately pondered every square inch of this question.  I am ready to deliver an answer the question:

No.  Nothing is ever good enough, but sometimes, it has to be good enough for now.  I don’t see any other choice.

(Now, where did that banana bread go?  It was on the counter just yesterday.)

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Psychology, Professionalism, Programming and tagged . Bookmark the permalink.

2 Responses to Is anything ever good enough?

  1. Tracy*_* says:

    Is your wife reading this? I am sure you aren’t a secret blogger 🙂 She must be knowing about your love for perfection as a programmer. But love and appreciation is a different concept. I don’t appreciate my colleague when they program the best app..I do it all the time for their effort and this is motivation. Direct suggestions can be a bit rude..right?

  2. Tim Golisch says:

    Heh. Yes, you are so right. Sometimes I forget that I’m not “on the clock all of the time”. When I’m not at work, I need to let the world be. I once heard someone talking about “the things that he could change, the things he could not change and having the wisdom to know the difference”. That skill manages to elude me sometimes. It is lucky for me that my friends and family understand me. Sometimes I still need a little reminder. Thank you for the wise words and encouragement.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s