Code Maintenance Part 3 — The When
This is the final article in a three part series about Code Maintenance. Previous articles in the series,
Hopefully, you are convinced about code maintenance and now you are trying to figure out when to do it. Let’s now talk about the When.
The When
Code maintenance and refactoring do not need to happen all at once, or even by a single person. The best way to do it is to make it part of the process. I am a big believer of the boy scout’s rule for coding.
Doing a little bit regularly, over a period of time, can significantly improve the health and quality of your project. Plus by design, instead of this task falling on shoulders of a single developer, becomes a shared responsibility.
Following are some idea on how can you make it part of your development process,
1. Reserve some bandwidth every sprint
If you treat maintenance activities as a first-class citizen, chances are you will never overlook them. In every sprint planning or quarterly planning, take up some maintenance tasks. Also, make sure you keep rotating the developers who work on them.
2. Always keep a bucket list
Sometimes there are unexpected blockers and dull period for a developer. They cannot proceed on any planned tasks. That is an excellent opportunity for them to pick up a code maintenance task. If there is a well maintained bucket list of such TODO tasks, chances are they will go through it and pick something that excites them.
3. Use every bug fix as an opportunity
No one likes when bugs are reported in a production system. The normal human tendency is to rush and fix that one bug. Instead, take a step back. Analyse why the bug was missed in the first place. Chances are you may find more bugs if you dig deeper. See if there is an opportunity to redesign something or write more tests.
4. Tie every new release with some maintenance activities
When you are planning for a new release, just bundle some maintenance fixes. New release are often tested thoroughly. This will give you confidence that your changes did not break something. Also, you will realize it is hard to convince your stakeholders for a maintenance-only release. But instead if you sneak in some changes with new features, nobody bats an eye.
5. Propose new features and improved experience to your users
This is my favourite method. Let’s say you want to rewrite a dashboard page that is already in use. Analyse it. See how are your current users using it. What are the gaps and issues, if any. Find multiple new features and enhancements that you can add for your users. Propose the new and improved Dashboard. If the new dashboard is genuinely going to bring in value to your users, chances are they will be very excited for it, and they would be very willing to give you extra time to build it.
However, sometimes you need to undertake that massive redesign task. And this requires time. Time that may not deliver any visible value to the business and hence you may get some pushback from the management.
Now, you can try explaining all the technical details to your manager. You can try to tell them that you will migrate your database form a server to a managed cloud, upgrade the Node version to the latest LTS versions, reduce the cyclomatic complexity of your services, refactor common APIs to be more abstract, introduce typings, increase coverage, etc.
In many cases your business counterpart will just nod and listen and eventually tell you: “I completely agree with you, but currently you should be prioritizing XYZ.”
Why should businesses care about maintenance?
Please remember, your job is not only to build software but also to translate technical jargon into its business value. At the end of the day, we do not build software just for fun. We build it because it brings some value to a business. So instead of talking about what do you want to do, talk about what value will it bring in. And as much as possible quantify things. Management loves numbers.
Following are some of the examples:
- Improve team velocity by X%
- Reduce new feature development time by X%
- Save X man-hours yearly
- Reduce overhead expenses by $XXX
- Reduce system downtime and bugs
- Help the team in XYZ audit compliance and XYZ security reviews
- Avoid inevitable catastrophic failures which may cause an expensive litigation
- Give a unified and improved user experience across systems
- Improve load speed by X milliseconds
I’m glad you read the entire thing 🤓
Do you agree with my thoughts? Do you have something you would like to share? I would love to read your thoughts and experiences.
Please leave a response below.
I ❤️ software development & enjoy writing articles about it. But they do take a lot of time & effort. If you have enjoyed this article please share & recommend it.
Happy coding!