You know a bad codebase when you see one. No tests. Big classes. Bad team communication. No issue tracking. No CI/CD. A lot of tech debt.

These are few reasons why you need to know more about repairs. Repairing bad codebases is cumbersome. Repairing software isoddly satisfying, when done right.

Set new coding rules

Don’t let your codebase slip away. Set up rules. Start with static code analysis. Progress with mandatory behavior and UI tests, on each build.

Rules can be simple. Don’t add more than 500 files in one PR. Don’t exceed the 1000 lines mark for classes.

Set up sonar to check Java code. Use Jenkins. Integrate code analysis into your build. Here arethe rulesfor Java.

Classes with thousands of lines of code, develop gravitational pull. Juniors can’t resist adding more code there.

I did this as well.

Separate logic as much as possible. Creating helper classes is better. Avoid putting more code in a big class.

Adapt code style. No flexibility leads to unstable software.

Setup rules for commits. Add meaningful messages. Even if you work alone.

Let’s say your project succeeds. You need more conditions, more logic. With no proper communication in commits, it becomes hard for change.

Address tech debt

Develop the mentality of tech debt. Debt accrues over time. You need to pay it back.

Look at software upgrades. You start with one version of Angular. Developing for a few months, a new version comes up. You now need to upgrade. Don’t overlook this. Plan for it, and adapt to the ever-changing software ecosystem.

When you patch software, log it somewhere. Know about that patch. When you have the time, get back to it and do a proper fix.

Find more on tech debt fromAlex Omeyer. He has good, extensive articles on tech debt.

Acknowledge tech debt. Developers know about it. Business people not so much. They see the fix worked, patched up, and continue a good job.

That’s why developers and business people need to agree. Agree on tech debt.

Let’s get to possible types of tech debt. This will help bridge the developer — business gap.

I likethis taxonomy of tech debt. It divides tech debt into three categories.

The good — releasing early

This tech debt is most beneficial. Go this way, to gather knowledge on the domain.

You can use the knowledge and improve. Pay the debt off, with a code refactor.

The bad — messy code

When you don’t test the code, you produce this type of tech debt. Also if you leave the code half-baked, this can also backfire.

This type of tech debt can cause serious issues. Unwise option to pick. Yet, we can see this code in our codebase. Identify, and plan for it, as soon as possible.

The okay: running an experiment

Running experiments produce not so bad tech debt. Both client and developer agree on this kind of debt.

The code behind it must be removable. I would place A/B testing here. Even if it causes issues, one could stop the test in no time.

Software mender or maker?

Are youa maker or a mender?

I love to work on stable projects. Improving the design of existing. Hence a mender.

When business is successful, the codebase grows. You have new customer types, new promotions, and new business issues.

Even when you start refactoring, there’s no end. You can improve so much, that you get overwhelmed. Hence we have rounds of refactoring, without any improvement.

That’s why this job, is a job for senior developers. They need to jump in. Tell us what is a better solution.

Leave ego when you start repairs. Accept critics, especially if you’re new to the project.

Don’t change tech, so you can solve a problem. Check dependencies. Do you need them? Even when you change tech, business models stay the same. It will grow into the same mess.

Conclusion

Maker or mender, we need to repair software. Bad codebases are everywhere. Use these tips and move further.

Know your boundaries. Ask questions.

Explore before changing. Explore idiomatic principles for your software. Explore OO design principles.

Resources

## Developer Differences: Makers vs Menders### While it's true that there are many software developers who do enjoy starting with a clean slate, there is also a group…corgibytes.com

## Agile Focus### Reviewing the community wisdom on technical debt, I am struck by the variety of definitions of the term, which are not…agilefocus.com

Sandi Metz is a big inspiration for this article

cover photo credits - Photo byBlaz ErzeticfromPexels