Compartilhar via

Seven Deadly Sins of Programming - #4

  • Artigo

Our next sin is the one that I've certainly been prone to.

Long ago my wife and I owned a house east of Renton, Washington (those who know about Renton at that time can probably understand why one would say "east of Renton").

Like many homes, this one had had various indignities committed on it by the previous owners. One of the most obvious was what can only be described as a "lean-to", constructed out of surplus Boeing shipping containers and shielding the washer and dryer from the rest of the garage.

After dealing with cold and dirty feet for a few months, we decided to convert the space to a real room, with features such as a floor, a laundry sink, a ceiling that was actually attached to the joists, etc. The framing went quickly, but when it came to the point of finishing the drywall, we ran into a problem.

My wife and I had very different ideas of how smooth a wall should be before it was painted. She wanted it to be mostly smooth, while I spent a fair amount of time with a light at an oblique angle, trying to get it really smooth.

I did the bulk of the drywall finishing myself in that room.

And after it was all painted, it turned out that it didn't really matter. Her standard was fine.

Which leads us, in the usual roundabout way, to our destination:

Sin #4 - Premature Optimization

Or, in other words, spending time on things that don't really matter in the end.

It's happened to all of us. You're in the middle of writing a class, and you think "a linear search of an array just isn't going to be fast enough here". So, you spend some extra time, and you use a hash table, or a tree, or a binary search, or something like that, and when you're done, you say to yourself, "now *that* isn't going to cause any problems".

And then later, when you're getting close to done, you run your code through a profiler, and you find that a) the array never has more than 3 elements and b) the code is spending a ton of time elsewhere in the code.

You wasted the time that it took you to do the optimization (bad), and you may have ended up with code that is considerably harder to read (worse), depending on how much optimizing you did.

How do you avoid this? I have two bits of advice:

  1. YAGNI came out of XP, and it's a good dictum to follow. If you are doing TDD, this is easier to do as you are more focused on making one small change and not on "finishing the class".
  2. Go read what a wise man has said about performance, and work on creating a performance culture in your group.

Comments

  • Anonymous
    June 26, 2006
    I prefer to say I live in "South Newcastle".

  • Anonymous
    June 26, 2006
    At the university our prof always told us "Optimization is a thing you can ignore while implementing your program. You can'T do any optimization before your program is running and you know where are the hotspots and what is the goal of your optimization"

  • Anonymous
    June 27, 2006
    So you finally admit it and I have witnesses!!!!

  • Anonymous
    June 27, 2006
    The comment has been removed

  • Anonymous
    June 27, 2006
    Mike,

    My experience - and the opinion of a fair number of people who have done more than I have - is that in anything but the most simple situations, developer estimates on how important one section of code is to the overall speed is pretty poor. It's just not possible to know enough ahead of time to do a meaningful analysis.

    Note that I'm not advocating putting optimization at the end. That does often lead to the kinds of ills that you mention, and at that point in the project there's often little that can be done about it.

    But facts trump thinking every time. That's Rico's point in his posts - if performance is important in your app, then you have to create a culture of performance where you measure performance in real scenarios throughout the project. That will tell you what needs to be optimized.

  • Anonymous
    July 24, 2006
    When I find my self branching out into premature optimisation type code that may not be needed, I usually encapsulate it so that it easy to expand on later (if neccecary).

    I find, this also helps highlight code that could be optimised later on; rather than allowing it to blend into it's surroundings and otherwise become unnoticed.

  • Anonymous
    July 24, 2006
    PingBack from http://technote.thedeveloperside.com/?p=56

  • Anonymous
    August 04, 2006
    So, the time has come for the worst sin.
    Just to recap - and so there is one post that lists them all...

  • Anonymous
    August 05, 2006
    PingBack from http://www.magerquark.de/blog/archive/374

  • Anonymous
    August 07, 2006
    PingBack from http://pyre.third-bit.com/blog/archives/598.html

  • Anonymous
    October 07, 2006
    PingBack from http://www.philwallach.com/?p=65

  • Anonymous
    October 10, 2006
    PingBack from http://bagofbeans.tsangal.org/archives/203

  • Anonymous
    March 19, 2007
    Double Check Locking and Other Premature Optimizations Can Shoot You In The Foot

  • Anonymous
    March 19, 2007
    After reading Scott Hanselman’s post on Managed Snobism which covers the snobbery some have against managed

  • Anonymous
    July 14, 2008
    I’ve been asked a few times about how to optimize LINQ code. The first step in optimizing LINQ code is...

  • Anonymous
    July 14, 2008
    I’ve been asked a few times about how to optimize LINQ code. The first step in optimizing LINQ code is

  • Anonymous
    May 30, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=1123

  • Anonymous
    June 07, 2009
    PingBack from http://weakbladder.info/story.php?id=3480

  • Anonymous
    June 08, 2009
    PingBack from http://toenailfungusite.info/story.php?id=3256

  • Anonymous
    June 13, 2009
    PingBack from http://homelightingconcept.info/story.php?id=1175

  • Anonymous
    June 17, 2009
    PingBack from http://patiosetsite.info/story.php?id=666