How to fix your awful tech that makes you lose money

Good code is expensive... And bad code is even more expensive, you just probably haven't noticed it yet. Although let's be real, you probably came to this realization recently and that's how you found this article, but because it took so long to realize that your issue is indeed your tech under the hood you have pushed yourself and your company into the corner. Don't worry, I can help you find your way out, just read carefully.

Symptoms

Just to be on the same page, I listed a few indicators that can confirm that you indeed have an acute tech problem:

You have a monolith application with 10+ years of history
Development speed has deteriorated significantly over the years
Your architects need to support the rest of the team in almost every development piece and they are overloaded
Newcomers need many months of onboarding and training before they can produce any meaningful output
Triaging a solution looks like a papal election
You can't react to changes in regulation reasonable time with your product
refactoring an older part of your application is unimaginable and is not a viable option
You never really allocated time for tech debts
Updating to a newer framework/language version is a pain and a months-long project, maybe not even worth the effort
New developers are hard to find

Even if you find just a single match from these, that should signal that something is going on and you should do something about it.

Are your architects actually good?

You probably have excellent technical people and this is not about me trying to suggest firing them. Rather, I would like to tell you what a good architect and architecture are like and help you choose the right people for the right job.

When devs arrive at the top of the seniority ladder and get to know the in-and-out of the technology, the most talented ones are given the "architect" title, this is how it usually goes, isn't it?

But there's more to an architect than technical excellence.

A good architect must keep a delicate balance of simplicity and complexity.

Let me explain...

Every architecture has design goals: speed, security, scalability, and most technically capable architects get it right too. That's what dev blogs talk about all the time while providing patterns and different ways of achieving these goals.

But a lot of architects don't take into account what I personally think is the most important trait of any enterprise application codebase is the ease of work. Good architectures have a clear separation between engine/technical features (the aforementioned design goals, such as caching, security, scalability-related code, etc.) and business logic and allow for business logic to be expressed in its purest form as free of boilerplate as possible, but still not overgeneralised as this leads to loss of flexibility.

Over my career, I spent an excessive amount of time fixing someone else's overengineered rocket-science architecture that only the author understood and where adding a property to a model took 3 days. The problem it creates is exactly what I glanced over in the Introduction - less-senior devs are pushed to the wall and constant architect attention and consultation are required which becomes a development bottleneck.

Good architects therefore must hide the complexity of the architecture from the eyes of the unattended while unlocking simple and straightforward workflows for the team without requiring them to understand the whole picture.

Ways of fixing

Get Audited

If your problem became severe enough, you should immediately reach out to a 3rd party expert company for an audit. Your team might not see the forest for the trees or there might be other structural issues that might prevent the real problems from surfacing, resulting in you spending money and time on fixing the symptoms.

An audit should highlight these issues both on code and organisation/structure level, but more importantly, give recommendations for mitigation. Such companies might even help you through the whole mitigation process, holding your hand or being involved as deeply as you like.

You need to spend time on technical debts

If your team didn't - or even worse - couldn't spend time on tech debts, then it should be changed right now. Everyone understands that business needs to go, but if the team wasn't able to spend time tidying up then it must be a mess they have to work in. It is like you didn't let in the cleaners, no one took the trash out and everyone left their dishes in the kitchen unwashed for a year. That's what it feels like to work in such a codebase and if it became acute then I can reassure you that it is costing you a lot of money as devs are held back significantly.

No matter how severe it is, since you came for this article, you should consult with your team and allow them time for fixing the piles of tech debts. I warn you, they might ask for anything between 1-6 months.

If what they ask is the higher end of the scale and you just can't afford to put everything aside for such an amount of time, I'd say that the best approach should be to do it in bursts as "tech debt sprints", so the whole business doesn't have to stop for half a year which would definitely sink the business.

Another approach is to dedicate an expert team solely working on modernising and fixing your beast, cooperating with the regular team or teams, that way you can progress with the business requirements, but keep in mind that it is less effective and requires a significant amount of coordination than just stopping and fixing.

But again, DO spend the time and don't cheap out on it as it is already backstabbing you. And just like that nasty imaginary office, now it requires significantly more effort to clean up than it would have been to just keep it tidy all the time. If this is intimidating you might instead ask a professional cleaning service to help:

Ask for professional help

If you or your teams are struggling to solve the situation, I'd most definitely ask for a third-party professional to help. We have helped many companies in the past in such situations and we've been always able to help greatly. You see, the problem rarely is that the tech teams are incapable, but working on the same product for a long time suppresses the ability to think out of the box. It's sometimes also hard for your team to suggest structural or workflow changes if the structure or workflow itself kills those attempts early in the process. What we found was rarely if ever just a technical issue, it was almost always accompanied by a lack of organisation, badly compiled teams, bad communication, failure to adhere to basic agile processes or (hive-) mindset issues, and even mismanagement.

A third party like us can not only provide you with a team of industry experts who dealt with countless companies and fixed tech-beasts like yours but have the ability to oversee the bigger picture, recommend changes and guide your people to make the right decisions or teach your teams to how to work more efficiently.

Conclusion

The main takeaway is that if you are in a situation like this:

Ask for external help as early as possible, get audited and/or involve specialists.
You have to spend money and time on the issue, otherwise, it will bring your company to its knees sooner on later in both aspects.
Make sure to nominate good architects.
Consult with your team and listen to them.