Skip to main content

Bottlenecks, Deer Hunting, and Software

Published: January 20, 2012

I see this a lot at work - someone puts code in a function. No, that part isn't unusual :) The part that "bugs" me, pun intended! Is that the code really belongs in the function that they have overridden (in the case of OO languages), or in the functions that they call (in the case of procedural and/or OO languages).

It's really a variation on some classic themes: don't repeat yourself; write as little code as possible; keep it simple; don't make me think.

One of the best ways of accomplishing this is to approach creating software like deer hunting. The best hunters know that there are certain natural funnelsĀ  - places where deer tend to run. These are the best places to put up a tree stand. You wait for the deer to come to you. You don't go running around trying to corral the deer. If there's a river, you find a place that is narrow and shallow to hunt because it is a natural crossing. Over time you'll see every deer in the surrounding area.

This technique also applies to software development. Find one place in the code to solve your problem. You have an additional advantage too - you can create the bottlenecks - the places where everyone crosses the river so to speak.

At work we have an OO based framework that all of our web apps use. The people who designed it didn't take full advantage of the natural bottlenecks. Rather than adding code to our Page_Load base method to check if the application should redirect the user to a "sorry, but we're down while the batch runs" page, they put code in EVERY page of EVERY application. Worse, they put a class in every application that is around 500 lines long. I did a diff between two of these classes. Less than 10 lines of difference. What does this mean? It means that 490 lines of code could be moved into a base class and the 10 lines of code could simply be overridden to provide the appropriate configuration values.

In short, the total amount of code in each application to support this feature could have been less than 10 lines of code instead of 500! In our current situation, if a bug is found in the duplicated code it would take us more than 100 hours of effort to update every application and deploy them. If this code had been put in a base class, we'd just have to update it in one place.