The “precious” legacy codebase

You don’t have to be destroyed as your codebase nears the end of its life

Most managers have an unrealistic idea of the value of their own codebase. This is a natural consequence of having maintained the code possibly for as long as a decade. “If 10 people spent 10 years creating the stuff, obviously it must be worth a lot, right?” I am here to tell you that such conclusions are fundamentally wrong. In fact, the more developers have maintained your codebase, and the longer you have maintained it, the less your codebase is worth! The reasons are obvious for anyone having experiences from software development spanning more than a handful of projects; Spaghetti!

The more people touching your codebase, the less consistent it becomes, and the more difficult it becomes to maintain. And the more difficult it becomes to maintain, the more bloat it automatically gets. The more bloat your code gets, the more difficult it becomes to maintain, and so on. This becomes a vicious cycle, where the codebase quality spirals downwards, to the point where its value becomes net negative.

If you don’t believe me, look at your own codebase. My guess is it contains dozens of libraries that are no longer actively maintained, or that used to be “best practices” a decade ago. jQuery, Durandal or .Net Framework for that matter? If your codebase contains any of these elements within, it’s destined for the scrapyard. Sorry for giving you a painful message here, but it’s the sad truth. Code doesn’t have value, in fact it has no value at all. Code has never had value, and it will never get value either. What has value, is your software suite’s ability to solve problems. As time passes, your codebase ability to solve problems becomes less and less, du to legacy code, bloated repositories, and obsolete libraries, to the point where it can no longer sustain its life. As it does, it is crucial that your codebase “spins of a child” (new codebase) to continue your ability to keep solving the problems your original code was architected to solve in the first place.

Facts are, code has a lifespan, just like animals and humans do. And when your codebase reaches the end of its lifespan, you can either accept it, throw it away, and do the big rewrite – Or you can choose to sink to the bottom with it, like the Captain of the Titanic. Everyone in the software industry having more than a decade of experience with creating software can easily echo my experiences here. Whether they have the courage to actually tell you though, is a different story. Don’t hire “yes people”, hire people that will guide you to the truth – Even when the truth is painful. This was the recipe followed by literally all great entrepreneurs, ranging from Bill Gates to Henry Ford. If you’re a manager and your company is maintaining a mountain of garbage, do me a favour. Go to the bathroom and tell yourself the following.

My code is garbage. I know this, and I must do something about it.

Accepting the truth, is the first step to recovery!

The Myth of Unit Testing

Would you want to hang here without a rope? The dirty industry secret is that you ARE hanging here without a rope!

Do you want to know a dirty little secret? In “real life” nobody are creating Unit Tests, at least not in my line of business. Every single time I have applied for a job as a software developer, I have seen lots of fancy buzz words about how they expect you to create Unit Tests, and expects the developer to create tests for every piece of code he (or she) creates. However, as I start my job working for the company, I discover that the test suite have a 50% fail ratio, if there even is a Test Suite at all – And I’m not allowed to make it work, because that is “unproductive work”, and we “don’t have time for such things”, and the test suite haven’t been maintained for half a decade. The irony …

TDD, xUnit, nUnit, Continuous Integration, DevOps, etc – Fancy words and all that, but all of these words are useless without a rich suite of Unit Tests. In fact, DevOps without Unit Tests, is like driving a spaceship, made out of paper, to the moon, without space suites. It will inevitably go wrong, and all sorts of shit is destined to happen.

I don’t know about you, but for me this is a real problem, making my life as a software developer that much more difficult, since it implies having to manually run all sorts of tests, for every piece of change I do, effectively making me 10x less productive in my “day job”. Regardless of how a company projects itself in job ads, and on LinkedIn, I’ll bet with 98% certainty, that their Unit Test suite is a joke. Don’t believe me? Go ask your own developers.

FYI, Magic has roughly 400 Unit Tests, and no I don’t have 100% coverage, and I could have better coverage, but my ~60-70 percent coverage, is roughly 60-70 percent better than the stuff that’s in your ATM machine, and your pacemaker. I find that fact quite scary to be honest with you …!! :S