(^78) 97 Things Every Programmer Should Know
Improve Code
by Removing It
Pete Goodliffe
Less is more. It’s a quite trite little maxim, but sometimes it really is true.
One of the improvements I’ve made to our codebase over the last few weeks is
to remove chunks of it.
We’d written the software following XP tenets, including YAGNI (that is, You
Aren’t Gonna Need It). Human nature being what it is, we inevitably fell short
in a few places.
I observed that the product was taking too long to execute certain tasks—
simple tasks that should have been near instantaneous. This was because they
were overimplemented—festooned with extra bells and whistles that were not
required, but at the time had seemed like a good idea.
So I’ve simplified the code, improved the product performance, and reduced
the level of global code entropy simply by removing the offending features
from the codebase. Helpfully, my unit tests tell me that I haven’t broken any-
thing else during the operation.
A simple and thoroughly satisfying experience.
So why did the unnecessary code end up there in the first place? Why did one
programmer feel the need to write extra code, and how did it get past review
or the pairing process? Almost certainly something like: