Leaving the codebase in a better state than you found it

I once worked for a company that threw away their frontend, React Native application before even releasing it to the public. Why on earth would you do this? Well, part of it was because the idea was flawed, user testing highlighted the lack of interest and the glaring issues. Furthermore, there had been many developers on the project and the codebase lacked Typescript, it only had JavaScript. These reasons above aren’t great, but the biggest sin of them all was the lack of constant improvement to the codebase throughout its life. For every ticket that was completed, there were zero tests to accompany it, there was no real code review process, multiple tickets were lumped together in one PR so that even if there was a review the reviewer had no idea what they were even reviewing feature-wise, and more often than not code was simply committed straight to develop half done causing multiple bugs that required hours to fix. All in all, no care or processes had really been put in place to run this project.

In contrast, that same company had a backend codebase that fortunately enough was started with Typescript and did follow best practices, reviews were done, commit message made sense, only one ticket to one PR was allowed and the biggest rule that was enacted was “Always leave the codebase in a better state than you found it”, what this meant was that every ticket we had we would immediately look at the surrounding code and see if there was anything that we could fix. If for instance, if it was too big to fix, say a major refactor of a section we would card it up and dedicate some time in a sprint to fixing it. If for instance it was some code that simply wasn’t clear or lacked comments, or just didn’t follow a consistent naming scheme, we would spend a little bit of time giving it some love. Improving the codebase by even 1% each ticket compounds overtime which is exactly why after a year on the backend the codebase was in exceptional condition and ready to go to production for months, whereas the frontend had to be rewritten immediately before a public release. Trying to understand how the code worked to add even the simplest of features resulted in about 5 other things breaking and hours trying to work out how the code even worked. The lack of code reviews, the lack of Typescript and the multiple developers that had come and gone could all have been fixed, slowly and over time. Sure it wouldn’t have been perfect but give it long enough and it could have been in exceptional form. It's the little changes that slowly build up over time. You don’t suddenly wake up and see that the whole codebase is suddenly perfect, it becomes less and less terrible to work with. It becomes easier and easier to read, extend and modify. Changing features or behaviour becomes less and less of a burden till overtime you can complete huge features in a fraction of the time you used to be able to.

Much like finances, the effect that compounding has is exceptional. It might not feel like much at the time changing a few names or breaking up a large function into multiple smaller ones, but the effect that it has when you do that for every ticket for 12 months is undeniable. It's why you see so many codebases that need complete rewrites because they didn’t follow simple rules. It's not sexy and it sure isn’t fun sometimes but sticking to it improves your lives and everyone who has to look at that code for months or years to come. It takes discipline and hard work to stay on track and it's the same for finances. You have to treat your code with respect, programming is a craft, as a result, it should be refined, polished and constantly improved. The codebase is never done, there are always things to fix, bugs to remove and old code that needs fixing. However, if you keep improving it all the time, it becomes easier to react to changing requirements, feature additions and the inevitable