How to Work with a Not so Perfect Codebase - Based on My Experience of Working in One!

There is a good chance that at some point in our careers we find ourselves working in a difficult, not-so-perfect codebase. Maybe the code was initially written for an MVP with hacky code but now you have a full-fledged product built on top of it, maybe the code was maintained for years by a number of people without a proper code owner and code review process and now it is just thousands of lines of code that nobody is there to own, maybe the requirements changed so dramatically that most of the already written code became obsolete.

If you become part of a team which is dealing with a scenario similar to any of those mentioned above or in general you are dealing with a codebase that is not very readable, consistent and easy to tread through, I have tried to put out a short list about how to manage through, bring sanity and actually actively improve such codebases along with developing features according to business requirements - based on my experience with working on one such codebase.

1. Acknowledge the Issues 🔧

After every member of the team has spent some time with the codebase, the first thing you want to do is to have a discussion among your team with everyone sharing their opinion and acknowledging the issues that exist with the current architecture, the way the code is written, the practices that are followed or the lack of such practices.
It is important to have all members of the team on the same page about what is wrong and what needs to be fixed.

2. Tackle One Problem at a Time 🔨

Do not try to fix everything in one night! When it took years to get there, it is going to take you some time to fix it.
Identify parts of the application or specific modules that need improvement, decide how much every area is critical to your operation and prioritize accordingly.

3. Respect the Business Objectives 💰

Most of the products/projects developed in professional settings contribute towards helping a business achieve its goals. For an organization, achieving those business goals is the first and foremost priority.
As a developer, we need to respect those business objectives and make sure our quest to 'improve' the code doesn't come in the way of achieving our business's goals. Always remember when you are there to cross the swamp and when to fight the alligators 🐊 (<-- I know this is a crocodile)

Cory House

@housecor

Working in a sloppy codebase under a tight deadline:

“I will have to remember ‘I am here today to cross the swamp, not to fight all the alligators.’” - Benjamin Zander

16:41 PM - 28 Jun 2019

192 866

Showing respect for the business objectives also helps you build a relationship of trust with the product requirement and specifications teams. This will help you get more time assigned to cleaning things up.

Cory House

@housecor

I should add: Developers don't enjoy working in a swamp full of alligators. It's stressful, risky, and hard to think clearly.

So:
1. I plan to fight the alligators soon.
2. I trust developers when they say "I've gotta fight this alligator first. It's in the way."

</metaphor>

19:33 PM - 29 Jun 2019

12 75

4. Establish a Code Review Process 👀 👀

Once you have agreed that you need to improve the codebase, the next step you want to do is to have a code review process. It is always better to put multiple sets of eyes on every piece of code that gets checked in. It is not necessary to have a senior resource review the code, initially, you could just start by peer-reviewing. This will also help the team eventually get familiar with different parts of the codebase.

5. Integrate Refactoring in Your Regular Bug Fixing/Feature Delivery ⬆️ ⬇️

Sometimes it becomes very hard for developers to get dedicated time assigned for code refactoring specifically especially in small to medium-sized projects with limited resources.
Continue your little operation cleanup along with every task, bug fix or feature you check into the code. This way every part of the code that gets touched will keep getting cleaned up without putting a significant effort at once.

All of my observations come as a junior engineer with 2 years of experience only, spending about a year with one such codebase and seeing it improve with each passing day. My opinions could also be biased only by the kind of teams and projects I have worked on.

Devs trying to find their way through such codebases, what do you guys think of this? Senior, more seasoned guys who have years of experience doing this correct me if I'm wrong or want to add something!