Tester's Digest

A weekly source of software testing news


ISSUE #14 - May 7, 2017

Today we talk about software maintenance and maintainability, a key factor in quality, in my experience. This necessarily connects to the topic of technical debt, see also an older issue:

Issue #7 - March 19, 2017 // Topic: Technical Debt

Topic: On Maintenance

On software maintenance and it’s substantial costs – 80% of total project time anyone? The posts suggests ways to lower the burden of maintenance, but that part is specific to Erlang:


“Dead code is not dead until it’s buried” and other thoughts on removing stale code, with a nod to Knight Capital disaster caused in part by activation of an old code path.


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”.


How to design (and build, and test) services for the real world:


The post links out to a services checklist which is great for both dev and test:


“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”.


How (and why) to design your code for testability:



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.


What actually happened at Knight, from devops perspective. Was it poor release engineering? Not enough automation? Error-prone process? This post offers analysis and insightful comments, too.


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

If you come across content worth sharing, please send me a link at testersdigest@mehras.net