Don't Do it… Yet.
- October 28, 2014
- 0 Comments
Early in my career I had the pleasure of working on a consulting job in Atlanta, Georgia. One of my friends on the project had previously worked with Neal Ford. Neal has written or contributed to several books about programming. I gained many insights from dinners with Neal, however the one that seems to come up most often has to do with code optimization.
Now truth be told, I no longer fully remember the context for this conversation, and this may have just been a throw away line to Neal, but it has stuck with me for a very long time. Neal’s first rule for code optimization was “Don’t Do It”.
I had to think about this for a very long time before I was able to recast Neal’s statement in a way that worked for me. I’m not sure what I took away from that conversation is what Neal intended, but I’ve found it very useful over the years.
I have lost track of the number of code reviews where I’ve looked at a very difficult to follow piece of code and asked a developer “Why did you use this approach? It seems very hard to follow.” Most of the time the answer back is “Well, this approach is more performant.” There are generally several problems with this statement:
First – did you actually create any tests that shows this approach performs better? Generally the answer is no, so we have harder to understand code for a poorly articulated goal.
Second – Do you have a good understanding of the overall goal this piece of code is participating in? That is, if you just saved me 30 milliseconds, but the next step is to communicate to a vendor system that operates on a batch basis, and won’t respond back for at least 8 hours, then the 30ms savings doesn’t really do much for us.
The biggest issue though is that, in general, most developers don’t think in terms of on going maintenance and support. They are not thinking about the person 3 years from now that will have to go through their code trying to find a bug, or diagnose a missed use case, and get lost in the “performant” (and confusing) code. These hidden costs, and the inflexible and unmaintainable systems they foster cost companies far more than simply buying a better server to run the poorly performing code.
The second part of Neal’s conversation around code optimization was (if I recall correctly) “…for experts only – Don’t Do It…. Yet”. There is a time to fix the performance of a set of code. That time is when you understand the overall problem. You have a test that shows where the problem is. You have an understanding of the full scope of the use case. You can articulate the business value of coding the more performance approach. Finally, once we have all of this, we can optimize.
Or as I tell our BP3 interns – first solve the problem. Once you know it is solvable, then worry about solving it well.