Maintenance is nearly synonymous with managing technical debt. According to this post, tech debt is not always quantifiable – it is a metaphor, but with a real cost. Some examples are: lack of test coverage (!), hardcoded values, misused APIs, redundant code, brittle error handling, missing or inaccurate documentation, reliance on old versions of third-party code, and more.

Tests need maintenance too! This post talks about pruning old / bad / irrelevant / duplicate tests. The one point I disagree with is the notion of retiring tests once a feature has matured because they won’t be finding bugs any more - my take is that you keep them to catch possible regressions in old functionality introduced by new work, that is the whole point of regression testing. Otherwise, prune well and often!

So, how does one go about building a maintainable system? Here are lessons from scaling Twitter, including “there is no such a thing as a temporary change or workaround: In most cases, workarounds are tech debt”.

“Every line of code written comes at a price: maintenance.” This post advocates writing disposable code over reusable code to minimize maintenance, counterintuitive as that sounds at first: “write code that is easy to delete, not easy to extend”.

Off-Topic

Since one of the posts above references Knight Capital, here are 2 more to shed light on the 2012 event when the fund lost a lot of money due to an automated trading system snafu.

This very long read provides meta analysis of a sort-of-but-not-quite postmortem of the Knight Capital accident, worthwhile if you wish to understand what does and doesn’t constitute a proper postmortem.

If you received this email directly then you’re already signed up, thanks! Else
if this newsletter issue was forwarded to you and you’d like to get one weekly,
then you can subscribe at http://testersdigest.mehras.net