You might have a case of technical debt
How technical debt will eat a business alive. It goes from a technical problem, to an organisational one.
If you are the manager of a software team that is struggling to deliver software in either a timely or your software ships with so many bugs, you might be affected with a software product that is dealing with a large amount of technical debt.
Technical debt is a term used for pieces of code that might save you some time when upon implementation, but will cost a lot of time to alter of make flexible.
Not all technical debt is bad. Imagine you want to test the waters of a new product. If your time to market is a sensitive aspect, you might choose to have a fast development cycle. If your idea does not have any traction, you haven’t spent the budget for a full product.
However, this technical debt is only good when it is isolated to proof-of-concepts or a codebase that will be actually thrown away after an event.
When reflecting on the technical debt that I’ve run into in my career, I’ve identified two origins of where this debt comes from.
Moving goalposts
These codebases might come back after management spots an opportunity in the market that is a great fit for what is already built. However, doing this might affect the motivation and trust that a team has in the vision and directives of management.
Your developers will feel betrayed, since they cut corners in the belief that they would never be confronted with this codebase. Good decisions are not made in a rush, and these codebases tend to be filled to the brim with decisions made on the spot, that upon returning to the codebase will certainly create friction.
The best way to handle these projects with technical debt is actually twofold:
First of all: Don’t do it. Codebases tend to resurrect, even though you might be convinced that you’ll never need a piece of software again. Even prototypes tend to zombify and give your team grief for years to come. A better strategy is to work on an MVP, in the real sense of the word.
Skip features that might not be interesting, or use substitution for pieces of functionality that don’t bring real value, like Billing (with e.g. Recurly) or authentication (with e.g. Auth0 or AWS Cognito). You might think that you wouldn’t want to give “the backbone of your application” to a third party. But this will give you more time to discover your market.
Once you’ve proven that your product works, it won’t be the biggest cost to implement these, and with cash potentially coming in you won’t have pre-financed it.
Secondly: However, if you did do it already, make sure you give your developers enough time to fix amends with the codebase. Don’t assume that changes will be minor. The most damaging sentence in any estimation, but especially in these types of projects is: can you do it in less time.
The rockstar took it away
Products get built in the budget that it has; many products will start with a proof-of-concept or an MVP created by the found itself, or by one of the trusted people. However, creating software that handles 100 people is very different that software that needs to handles millions.
In the same vain that founders might not be the best CEOs in later stages of the company, the software written in the early days of the business might not be the best idea after five years of running a business. Where the founder might have a hard time hiding from the board however, the codebase might sneak away for longer than it should.
These software projects might be very harmful, because it has the ability to eat trust between teams. When the company grows, a few or lots of developers will arrive at the project, confronted with a codebase that doesn’t follow industry standard, or was written by someone who didn’t care about working in a codebase. that needs to be given to a team.
Technical debt in a project makes it very hard to make estimations about, because any change might introduce dozens of bugs that weren’t foreseen. Your developers will start to multiply there assumptions, and there is a real chance that they still under did it.
Other managers will challenge the estimations, see that they get overshot and/or get frustrated. They’ll start to question motivations, meetings become more about finger pointing than returning results.
Resolving this type of technical debt in a software project is quite hard. The solutions might be:
- a rebuild, which requires an extreme amount of planning and will result in having to ship a new version with less features. Keep in mind that lots of businesses and governments tried to do this around the 2000s and utterly failed because the enormous undertaking that something like that might be.
- freezing features or parts of a codebase, or the whole codebase to start removing technical debt. This might end up in developers having to tackle lots of side effects throughout the application and might be very hard to estimate and to keep tabs on.
Neither is perfect and comes with a set of challenges. The real trick in managing this or any technical debt is understanding that some might be introduced, but having ways of identifying and addressing it fast. When only one or two classes need to be changed, your technical debt might be resolved in no-time.
You can actually do some simple organisational tricks to make sure that you won’t hit this stage: let your team do code reviews and testing, always giving your developers a budget to work on technical tasks, or just have in wall of shame for pieces of code spotted in the codebase. Also make sure your developers can also invest time in tools that helps in the maintenance of a codebase like writing automatic tests that will allow changes to the codebas to be easy, or investing in static analysis tools that will stop bad code in its tracks.
But the first step should address the communication side of things. This one is twofold. First of all, why did your developers not raise the issue. Or did they do it, and was it ignored.
On the other hand, make sure that the people that had lost trust in the team are informed. Tell them about the steps and the plan you have for addressing their issues, how this was cultivated and what you are doing from preventing it to happen in the future.
Hopefully you will have gained some insight. What’s your opinion about this. If you have any further questions about leading a technical team, feel free to contact me via niels@codingculture.be or via a social media platform.
