In every software project I’ve ever been involved in, there was always this issue with code maintenance.

Newer practices, language versions or frameworks are released, and a year-old project become a legacy so fast due to code rot.

In the past, I heard some people say, we don’t have to have the latest and greatest, we don’t have to learn the most recent best practices or code styles, some people say: we’re fine. If it works don’t fix it!

These are the kind of engineers that decided to stay behind and settle for less, and I promise you, given enough time these very same engineers will have no clue how things work anymore, all they’ll have is some tales from the good olden days or fight you ferociously when you try to introduce newer frameworks, language version upgrade or anything related to modernizing the software.

When this kind of has-been engineers are in power positions, due to their seniority not their leadership skills, they become an obstacle in the way of innovation, modernization and the contentious growth of the poor souls they manage.

Because modernization inspires continuous learning, innovation and keeping up with the times, and all of that requires effort, and in the software industry if you’re not wholeheartedly into engineering you’ll run out of breath so fast.

But staying up with the times requires it to become a fundamental part of every engineer’s daily work.

I have come to realize that a systematic approach is needed to make sure the team is in a continuous state of learning and innovating while still being able to deliver value.

This very practice is what makes an engineer feel valued, invested in, and makes them willing to stay longer at their positions because they are getting more than just a salary or a benefit out of their job.

That’s because investing in the continuous learning of engineers is just as important as their salaries, simply because their continuous growth is the only assurance they have to ensure they will stay relevant in the industry and continue to do what they love to do without wasting eight hours of their day working on some outdated irrelevant technology or skill set that has no use for them anywhere else.

And because of all that, maintaining software has become more important than just keeping the software running seamlessly and decreasing its faultiness, maintaining software becomes more of a maintenance process to the knowledge of the engineers working on this project as well.

Here’s some of the requirements I needed to achieve when I first thought about code rubbing:

1. Engineers need to stay relevant, up to date with technology and coding best practices to produce better quality software.
2. Engineers need to develop a sense of pattern for the consistency of code, and potentially to develop their own pattern and best practices.
3. Engineers need to familiarize themselves with every single file in the solution to be able to pinpoint any potential issues in production and be able to rapidly fix them.
4. The solution itself needs to be in a continuous state of maintenance to ensure its relevancy in the market and betterment of user and developer experiences.

The order of these requirements is intentional, because good engineers produce good software not the other way around, it doesn’t matter how advanced modernized or up to date your software or your process is, if you hire bad engineers they’ll turn it into a Dutch oven as fast as the rates of gravity.

So, engineers here are the top priority, and therefore I devised a software maintenance strategy that I called code rub.

Code rubbing is just like glass rubbing, it makes cleaner, shinier and better to look at.

In order for that to happen, every engineer will need to pick up a random file from the solution they are working on, and make sure it follows the best practices and latest technologies, along with making sure it maintains it’s consistency across the entire solution.

But there are conditions for code rubbing, which are:

1. It shouldn’t take more than 20 minutes from an engineer’s day.
2. It should target only one single file per day.
3. It shouldn’t include implementing new features or fixing bugs.
4. It should require more code reading than code writing.
5. It shouldn’t require a pairing session.
6. It should be done continuously every single day.
7. It shouldn’t happen to the same file by the same engineer twice unless every other file has been already rubbed.

Sometimes the file you pick up might not require much change, in that case an engineer’s code rubbing task is done for the day and they are ready to work on their daily tasks.

Code rubbing inspires conversation among the engineers to find better ways and learn from each other, conversation result in innovation when egos and pride are set aside.

In a team of seven engineers code rubbing a solution means that every single file in the solution has been reviewed, maintained and read at least seven times before it was beta released.

And the more an engineer rubs the same code the more they learn about it, it’s like reading a book more than one time, the more you read the same book, our brains automatically skips through the obvious and looks for the unfamiliar to learn from, so is the case with the code.

But code rubbing also means that every engineer will be producing a new pull request every day, pull requests make engineers happy, especially when they are working on a long running sprint-long task and they haven’t merged anything in a while, code rubbing gives engineers this feeling of accomplishment and belonging to the project, especially newly joined engineers.

In an Agile methodology, every engineer should have a code rub task for every day in the sprint, a two weeks sprint will require ten tasks of code rubbing, whether the code requires a rub or not, creates a pull request or not, the task moves to completed just for the mere effort of reading through the code and making sure it’s in shape, regardless how big or small the file is.

There’s a mindset in the industry that code must be written right from the very beginning, it has to be perfect from day one. But the reality is that code is perfect only for a short period of time until a better practice, technology or a language version is released, that’s when the code immediately becomes outdated, faulty and harder to maintain for newer engineers.

In contrary of what Robert Martin (Uncle Bob) says, that code rots because people who are working on it are rotting it, but in reality code actually rots by itself due to the continuous state of advancement in technology, not just by bad engineers not following practices and regardless of what the cause of rotting is, the goal here stays the same, code rubbing to ensure cleanliness and relevance.

Multiple teams and myself have started the code rubbing practice in the past several weeks, and I have to say the results have been inspiring enough to share this experience with the world in this article, inspiring enough to recommend it to every software development team out there given the team have already settled on what their coding standard will be, and how often after a release they are willing to upgrade their libraries.

A software development team without a coding standard is like trying to fly a spaceship without a manual, it’s not a good idea, and if your team doesn’t have a standard, they won’t be able to perform code rubbing, simply because what one engineer sees as a best practice, another engineer will come later and undo their work, it will be like trying to fill a broken jar with water, it retains none, and it’s a waste of time.

At the end, I like to think of code rubbing as a product of innovation, systems that we devise due to our accumulative experiences for the betterment of the software development process, and as we continue that practice, I’m sure we will learn more along the way and continue to produce better systems and practices, adjust our existing processes as we go to help us get to where we are going faster.