What’s The Hidden Cost of Bad Engineering?

If you think good engineering is expensive, you should see the bill on bad engineering.

This quote stuck with me because more often than not it's indeed quite accurate. Have you ever heard “We don’t have time to do it properly!” Right?

We've all seen our fair share of seemingly working bad software engineering[1] and we know that waiting for the perfect engineering solution won't get projects completed on time - waiting in this case is rewriting code over and over - redesigning, refactoring, make it more testable, …. So what do we do when we have to deliver? We take those time critical shortcuts known as technical debt to get results. You know, it’s working for this case or it’s hardcoded for now, etc. the typical fire and forget. This is natural and there’s often nothing wrong with it so far, but if it’s one of those hacks that causes more work every time that piece of code is built or linked or touched, … then, not taking the next step is where the mistake happens.

Once the time critical phase is past and the deadline was met, the issues that are still causing lost time and thus lost money should be addressed as early as possible unless you’re consciously willing to live with a much higher cost of maintenance, code complexity and sometimes even frustrated developers. Keeping hacks and workarounds is like an unpaid credit card bill: it creates short-term liquidity but it won’t be cheaper.

The best you can do is to make - not wait for - time to get back to fixing it. Keep a list of things you want to fix and keep it prioritized and make sure the team and project owner have ready access to that list. On the upside, keeping the list available also gives you and your team time to think about the best solution.

Thus leaders, please keep explaining to your team members or peers why it’s necessary to keep those things around - and if you can’t keep a straight face doing so, you know it’s past time to fix them. Developers: understand your leads if they tell you that you don’t have the luxury of a second shot at the problem, but also keep bugging them (in a kind and respectful way) about it, if it keeps bugging you afterwards.

One strategy that can be used is the rule-of-three: hack it the first time, invest the time to get it done the same or similar way the second time and fix it for good the third time. That means you’ll have had two chances to think about how to properly solve an issue before taking a stab at it.

So what is the cost of bad engineering? Unfortunately, only you’ll be able to answer but we’re happy to provide some hints: Do you follow best practices to get rid of technical debt? Have you asked your engineers where and how much they keep losing time? At worst, have you had people quit in frustration? If you’d like us to take a neutral look into your processes and ask around, please don’t hesitate to contact us today!

Engineering is indeed an art and often the greatest things achieved do carry a few ugly hacks in the backpack that only insiders will know about.

[1] One of the more funny things I have seen in my career was a link to Google Code Search (RIP code.google.com) with the title list of buffer overflows and the regex along the lines of malloc.*// should be big enough