Refactoring – Basics for Management
Refactoring is the process of restructuring existing code to improve the design, structure, and/or implementation of the software while preserving its functionality.
Always leave the code behind in a better state than you found it.
Robert C. Martin
The Usual Process
Over the last few years while working in the role of Software Developer and eventually leading the team of software developers I got the chance of working on multiple varied sized projects. In each of these project, the life cycle of the project progress something like following –
- Business comes up with an idea that can save a million dollars for the company
- The highest priority for the business is to release this new idea as a product in the market to get the early feedback resulting in tight deadlines.
- Even the earliest prototype project becomes a big project with dozens of features.
- The software development team works on these tight deadlines leave behind multiple code-smells and design problems believing that these will be handled in the cooldown period after the big release.
- After the big bang release, the priorities changes and the focus changes to other projects and team members are redistributed for the next big idea in some other project
- The code is left in the same state in which it was developed and is revisited only when a new feature needs to be introduced.
- The business is now in dilemma – The cost of refactoring the codebase for better maintainability does not give any immediate benefits to the business but the new feature development is now taking longer and longer.
- Again because of deadlines the new feature development takes precedence over the refactoring the code
- The features are not completed within the deadlines and the development process starts slowing down considerably.
The Root Cause
The root cause of this problem is that code refactoring does not have a clear benefit that the management can see right away. And although everyone always talks about writing maintainable code, no Business wants to push the delivery date to accommodate the code -refactoring.
Business usually is forced to agrees on only Major refactoring when the system starts to show some major problems in the production or when the cost of adding new features becomes too high.
The business case for Refactoring
The strenuous responsibility of a tech head in a project is to convince the business to implement the code refactoring changes. Some times, the program managers also favor taking up new features as they add direct value to the customer.
A good tech manager can use the following pointers to convince the management of how the code improvement will benefit them
Consistent on-time delivery for new features
Inconsistent delivery time not only causes issues while doing the resource allocation for a team but also leads to badly planned project roadmap execution.
Usually, the inconsistency of delivery time while adding similar kinds of features in the code is a sign of code smell. This is a very common problem that occurs in almost every system.
Code refactoring will help team to give consistent timelines which can help business to better plan the resource allocation of the team to other projects but also in planning a better road map for the project.
Improvement in the dev cycle time with a reduction in Dev cost
Have your team or Business ever felt that the delivery time can not be justified because the change is should have been a really small change.
Reduced Risk of production bugs
explanation
Reduced Risk of dependency on individual developers
explanation
Improved Performance
explanation
Reduced overall Risk
explanation
Software Developer’s point of view
- To improve the design of software/application.
- To make software easier to understand.
- To find bugs
- To make the program run faster.
- To fix existing legacy database
- To support revolutionary development
- To provide greater consistency for the user.
