Most codebases start out fresh, tidy, and easy to maintain. Over time, they fall behind on modern coding standards, extensibility, performance, and other aspects. This is can be slow or rapid depending on the team. From this deterioration, Technical Debt is born and it begins its slow but inexorable gravitational pull on the software, the team, and the business as a whole.
Everything has a life span, and technology generally has a shorter lifespan than most things. Well architected and maintained code can last for a decade or more – but how do you know whether it is in a productive middle age or nearing its end of life?
If you running 5+ year old custom software, read on…
Here are 5 uncomfortable but real truths you should know about most aging custom software:
- You have significant security holes: New exploits discovered and patches rolled out several times a quarter on all the layers of the application. OS, Web server, frameworks, database, Javascript, etc. Do you know for sure if you are full updated?
- Your developers aren’t telling you everything: Once a product team goes into steady state/maintenance – senior talent generally loosens their scrutiny. Code reviews and design decisions are made by more inexperienced members, and the code becomes patch work. This also means that inefficient practices become normalized – causing performance and maintainability issues. Then, because management rarely likes to hear the word “refactoring” – these don’t get escalated.
- Things are taking too long to get done: This also means that enhancements requests take 2-3X longer than when the codebase was new. The current codebase is probably a long way away from the original architecture, and now there are 3-4 completely different styles of coding and design in play. This means repetitive work, hard-coding and a “just make it work” rather than a “do it right” attitude.
- Your users are doing repetitive workarounds: Since new features are not coming in as fast as expected, and even bug fixes take a while – users are doing workarounds using excel or other tools and while you may or may not be hearing about it, they are blaming the technical leadership team.
- You are terrified for when that one developer quits: You have that one developer who understands the whole system that everyone depends on – and if they quit well then you don’t know what you’d do
What are your options?
Think through the following aspects to decide what your next steps are.
- Enhance Vs. Rebuild Vs. Rent: If you already sense that things aren’t perfect with an aging codebase, you need to start thinking about your 3 options:
- Maintain and enhance: If you feel the codebase will meet your needs a few years from now, then it may be worth the time and effort in maintaining and enhancing it
- Rebuild from scratch: If the codebase/architecture will not meet your needs 2-3years down the line – you need to start thinking about rebuilding and migrating the data
- Rent: Looking at the marketplace of packaged applications or Software as a service is not a bad idea. Your decision should be based on how much of your Intellectual Property and core business functionality is dependent on the software. If the software is not providing a unique competitive advantage then you may be better off using an off the shelf app.
- Is the current codebase sustainable? First you need to make a call on whether your current codebase can be resuscitated. Your current team may have biased opinions so you need to get an independent assessment on what reality is.
- What are your users asking for RIGHT NOW? Customer needs are ever-evolving and your business is too, but how far behind has the codebase fallen in serving these changing needs? It’s not just about is it doing what it was designed for – the question is – will it meet the needs of the future?
- Is doing nothing actually costing you big bucks? There are two components that could cost you dearly:
- Inefficiency: Old codebases can be tricky and fragile so adding new features are higher risk, harder to enhance, and slow. This means the same feature built in a brand-new codebase using modern coding practices could be 2-3X faster. Typically support and maintenance are less than 10% of costs for a new codebase with 90% going towards new features. That ratio keeps changing to where steady state is more like 50-50. Old codebases leak money and it adds up.
- Opportunity Cost: This is an under-appreciated but super-critical aspect of budgeting and decision making. You could deploy resources more efficiently or go after a brand-new customer segment but you are saddled with the current constraints of working with the old codebase. How much money are you leaving on the table for your competitors to pick up?
Unnecessary risks are for noobs
As Donald Rumsfeld said there are 3 categories of knowledge: Things you know, things you know that you don’t know, and things you don’t know that you don’t know. If you get hit by something you never knew about – that’s just hard luck. However, when someone knows the costs and risks associated with aging software and still continues to expose themself to those risks – well they have no one else to blame.
But it doesn’t have to be that way. Take the known unknowns and make them fully known with an independent review that gives you the information to make the right decision for the long term.
Need help? Reach out to us at [email protected] to learn how our code and architecture reviews can radically cut costs and improve productivity for your team! Our assessments cover code quality, architecture, security, functional quality, performance, team best practices, and much more.
