Seven Deadly Sins of Programming – #4

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 (21)

  1. Ricky Dhatt says:

    I prefer to say I live in "South Newcastle".

  2. roman says:

    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"

  3. Wife PhC says:

    So you finally admit it and I have witnesses!!!!

  4. Mike Dimmick says:

    I’d argue that doing the hash table, binary search, etc is not premature optimization IFF you know that it will be needed. That is, you’ve thought about the cardinality of the data – how much there’ll be, and how critical the accesses to it are – and choose your data structure or search algorithm appropriately. Choosing right now can save rework.

    I do see the ‘premature optimization’ quote given out as an excuse for not thinking about the cost of operations, and that often ends up with an unusable first alpha, beta, or even an unusable production system when it’s finally presented with the actual volume of data it needs to handle. In particular, OLTP database systems without enough thought into archiving and analysing historical data, allowing volumes of inactive data to build up.

  5. ericgu says:


    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.

  6. r3n says:

    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.

  7. So, the time has come for the worst sin.

    Just to recap – and so there is one post that lists them all…

  8. Double Check Locking and Other Premature Optimizations Can Shoot You In The Foot

  9. After reading Scott Hanselman’s post on Managed Snobism which covers the snobbery some have against managed

  10. I’ve been asked a few times about how to optimize LINQ code. The first step in optimizing LINQ code is…

  11. I’ve been asked a few times about how to optimize LINQ code. The first step in optimizing LINQ code is