Follow These Steps To Rebuild Trust In a Codebase
When a codebase is not properly maintained while it grows, it reaches a point when the developers working on it no longer trust it. If this keeps going for long enough, new developers will pick us this mistrust from the existing developers, and the problem will only keep growing.
Imagine that you inherit that codebase, and now it is your responsibility to rebuild trust in it. How do you go about it?
Signs of lack of trust and confidence
Let’s start by defining the problem.
A group of developers working on a codebase they can’t trust will or may:
- Avoid fixing bugs for fear of breaking something else.
- Favor solutions that minimize their risk, although they are not the best for the product
- Avoid refactoring
- Avoid suggesting improvements
- Avoid reporting bugs they found because once you report them, they become your responsibility
- Inflate estimates
- Avoid committing to anything as much as possible
What can you do about it?
Set up linters, formatters, and any other cosmetic tools
Make the codebase look familiar to you and the team. This may seem like an odd place to start, but the sooner you can make the codebase feel less strange to the developers, the sooner they will start feeling invested in it. I’ve made the mistake I’d waiting too long to do this, and I’ve regretted it. Nobody likes working on a codebase that reaches this state, so anything that can make the codebase feel closer to the developers is a good thing
Explain the situation to product stakeholders
If developers do not trust the codebase, chances are stakeholders do not trust the product because such a codebase can only result in a fragile product. Especially if improving this codebase has been tried before to no avail, sharing your strategy and making them part of them will help you get their support. You’ll need it.
Start defining your testing strategy
Tests are THE biggest tool we have to build trust in the codebase. You may find developers who are against them and consider them a waste of time, especially in a codebase that’s past the point of being saved. If your strategy is “to build tests,” you’ll be faced with skepticism.
Your testing strategy should make it clear that you understand what the key areas of the product are, what the main points of conflict in the codebase are, and what types of tests you suggest for tackling those. Aim for tests that quickly give you the biggest coverage and then focus on lower-level tests. Worrying about code coverage is probably a waste of time at this point, but prioritizing which areas should be covered first is a good way of approaching the situation.
Understand which parts of the codebase are obsolete and get rid of them
All codebases that get to this state will have parts that are no longer used. These areas will probably be unmaintained, undocumented, and nobody knows what they do. The best thing you can do is to remove them as soon as possible. They don’t provide any value, and in fact, they are hurting the codebase.
If you are new to the codebase, finding those areas will not be easy. Your best bet is to work with the product stakeholders, but they may not even be aware some of those areas still exist. In those cases, git is your friend to spot areas that haven’t been touched in a long time. Eventually, you’ll learn with time where these obsolete areas are.
Break down the codebase into functional areas and understand what it will take to address each one
Depending on the size of the codebase, addressing the trust issue can be daunting. Breaking it down into functional areas will have two benefits. On one side it will allow you to focus on a smaller scope, reducing complexity and increasing the chances of actually delivering value. On the other hand, it will show stakeholders that you are not approaching this as a purely technical benefit; instead, you understand how this codebase is supposed to support the business.
Once you have an idea of these functional areas, make a high-level plan for each one of them. You don’t need to work out all details here but sharing with developers and stakeholders whether a particular area is expected to be refactored or completely rewritten will make your plan more real and relatable.
Encourage the developers to take risks
Doing what’s best for the codebase and not the safest for the developers is risky. Patching something to fix a bug has a lot less chance of breaking something but it is guaranteed that it will make the codebase harder to understand, contributing to the lack of trust.
Encouraging taking the risk to do what’s best for the codebase implies, first of all, that you take the risks first and then have your developers’ back when they take the risk and things don’t go as expected.
Share your strategy
For people to start believing the problems will be addressed and things will change, they need to know that you have a plan they can buy in and support. Share it early and get feedback. I made the mistake of waiting too long to share my plans because I wanted them to be perfect, and then it was too late.
Combine quick wins with long-term success
The main problem of the codebase can be a core area in it, and you may want to tackle that first to fully remove that huge pain point. But if that will take months, it will be hard to keep people engaged and believe something positive will come out of this enterprise.
If you can, try to combine those long-term successes which are critical in your strategy with short terms wins like fixing a bug that’s been annoying the team for a long time or creating some high-level tests to reduce the pressure in manual testing, anything that will show results fast and often to keep developers and product stakeholders alike engaged because they see constant results.
Accept that you may never rebuild the trust
Trusting the codebase is more than having tests and clean code. Trust is psychological, it’s a feeling. Trust can be undermined by having been burned once too many times and blamed for it; trust can be undermined for having flagged these problems once too many times without anything being done; trust can be undermined for having seen once too many people attempting to deal with the problem saying this time will be different. You can change the environment and show there’s a way to start moving in the right direction, but eventually is up to others to take your ideas on board. You can only do so much, and you should make peace with that.
Conclusion
Rebuilding trust in a codebase is a difficult business. To achieve good results, you will have to approach it with empathy because it’s not just a technical problem that can be fixed with cleaner code; it’s a people problem too. And you will need product awareness because you will also have to build trust with your stakeholders.
Have you dealt with this problem before? What was your strategy to approach it?
If you found this article helpful, please consider clapping or following. You may be interested in checking out other articles: I write about software development, management, and leadership.
