And you are here why?

“ Code is either growing or staling ”  —  Me /via https://www.monkeyuser.com/2017/unit-tests-coverage-degradation/ When we think of Legacy Code, we usually think of it as  a pejorative . If we’re a bit more enlightened, we might think of it as “ all the code you’ve written, all the frameworks from the past, all the processes that exist to deal with edge cases, and all the skills that you no longer use ” (•) Which is all well and good, except that one of the most important components of legacy code is all the tests embedded in it. Think about it this way — it’s really pretty hard to maintain test coverage on your  existing code, right? Now imagine doing this for one of the legacy systems. The sequence probably goes like this 1.  Somebody reports an issue 2.  You poke around in the code, half-remembering how stuff works, and eventually produce a fix 3.  OH NOES, some of the tests staled out due to the fix, others ‘cos data has changed, and that’s ...

Way back in 2014 Yuan et al conducted  an analysis of production failures that brought down distributed systems  (•). They went through 198 random failures in well known distributed systems like Cassandra, Hadoop, and whatnot, and, well, the results were remarkably depressing. Basically, they found that for most of the  catastrophic  failures — where the entire system went down — the root cause was ridiculously simple. How simple you ask? Well, it turns out that around 90% of them boiled down to non-fatal errors that weren’t handled correctly. Yeah, I’ll let that sink in for a bit. Bad error handling. That’s it. Ok, now that it’s sunk in, let’s make it worse. 35% of the catastrophic failures boiled down to one of the following three scenarios 1.  The error-handler catches an overly general exception (e.g. an  Exception or  Throwable  in Java), and then shuts the whole damn thing down. BOOM. 2.  Or, better yet, the error-handler a...