because efficiency
Part of a series of posts that discuss justifications for spending more time on a specific piece of code, rather than continuing onward.
The efficiency justification for polishing code goes something like this:
This bit of code does what it’s supposed to do, but I don’t like that it takes more than <insert resource consumption>. I can do better.
This can be the consumption of any resource — CPU, disk, network, memory, or time.
When does efficiency mislead us?
Just like cleanliness, the preference for efficiency gets in our way as soon as something is efficient enough, yet we push forward and work on making it more efficient anyway.
Why does this happen? Essentially for the same reasons that cleanliness, and other engineering principles are followed — as engineers we often identify with being engineers, and taking pride in our work so much, that we’d rather our work be an example of great engineering that almost anything else. While this can lead us to some good places in terms of overall quality, it’s very possible that the organization for which we’re writing our code doesn’t primarily make its living on the quality of its code. In fact, the profession of programmer is so widespread now that writing code is very often just a necessary part of some other, much more important part of what the business does. This is why it’s so important to know what is efficient enough, and stopping there.
When is efficiency helpful?
Our software cannot consume infinite resources. So we need do need to draw a line somewhere. However, talking about what is good enough is what we need to focus on.
