I was sitting on the deck of my house this morning, enjoying the early spring weather, when I noticed that a railing on the stairway appeared to have a rotted section. Sure enough, the railing, built many years ago, needs to be replaced. Thankfully, it’s just a railing, which is within my limited realm of carpentry skills. But it got me thinking about the deck, which my pal Currie built for my family last summer: Which parts would be most difficult to replace, if/when I need to some day? Thankfully, Currie did a swell job, so I hopefully won’t have to worry for a while. A railing I can handle — but what if one of the floor boards or a corner post of the railing rotted? For those pieces, I found myself glad that Currie had stained and painted thoroughly and with primer coat.
It’s similar with software, I think. Ideally, every component of the system is thoroughly tested and simply designed. But in reality, we make tradeoffs, and some pieces are of lesser quality. The key then is assessing those places that need the most strengthening. So it can be a useful exercise to look at your code and ask, “Which areas of our system would be the biggest headache to fix/maintain/build on if something went wrong?” And then, “Which areas of our system are in the best shape?” If you have to choose, spend less time testing and refactoring those areas that, while no fun to fix, are still within your ability to easily do so — and spend more time on those foundational places that interact with many other components and “corner posts” that would require a huge redesign and undertaking to get your system back to a workable state.