Empower programmers and avoid large scale refactors
Lengthy refactorings are difficult, and often fail, whereas small refactorings are usually easier and succeed. Teams should encourage programmers to continually make small scale refactorings in order to avoid large ones.
Only programmers can make small scale code decisions
At RES, we are lucky in that our Product Owners and Managers are highly technical. My manager started his career in the software team, and has recently written an iPhone game in Python. Alex wrote many R scripts, which are still being used to predict wind turbine failures, and is also a dab hand in Python. Polys is still at the leading edge, and is our Kubernetes and enterprise architect specialist, and I am our software quality champion.
We have cross functional teams, and the product managers spend their time on a multitude of complex things. Outside of the source code there is people management, stakeholder management, project management, budgets, recruitment and so on. Product managers must also manage the competing demands on the team to ensure that we are working on the highest value features. This leaves them with little or no time to look at or work on code.
We, as managers, have worked hard to remove distractions and waste from programmer schedules, so they, on the other hand, spend a great deal of time working directly with the code, developing new features, refactoring, reviewing and so on.
This means that, even with the impressive array of technical software skills throughout our teams, the programmers are the only ones capable of making the majority of decisions about the code.
Large scale refactorings are difficult
A refactoring that takes 2 weeks is hard to sell to the business. The code probably can’t be released or maybe even compiled during the refactoring, and the tests probably don’t pass. This means that it is very hard to measure progress and know when it might be finished.
The business only has visibility on new / modified features (at least in the short term), so it looks like nothing is happening, and the real or apparent lack of progress understandably makes them nervous.
An unexpected delay (which are common, so it’s surprising we haven’t learnt to expect them yet) could cause a lot of problems. Resources earmarked for different projects might suddenly become unavailable, promised features might not be released, opportunities might be missed, knock on problems could affect other teams.
Life is also difficult when implementing the refactoring, mostly for the same reasons. It is often hard to predict when the work will be done, and the business wants to know. The code often doesn’t compile and the tests often don’t pass, which leads to less confidence in the code changes. Often the task is really important, and so the difficulty is underestimated, in order to get it approved. All of this leads to an incredible amount of stress as programmers desperately try to get complicated changes done under pressure.
For all these reasons lengthy refactorings are unpleasant, and a reasonable proportion never get completed, maybe because the business runs out of patience, or maybe because the change is just too difficult.
Large refactorings can be replaced by many small ones
The vast majority of large scale problems arise from a build up of small ones, so it seems that the solution is easy, just perform small scale refactorings as they are needed.
However most people feel under pressure to work fast, for various reasons.
Sometimes our estimates are wrong, so we are behind schedule. Sometimes there are deadlines we should meet. Sometimes we put pressure on ourselves, because we think that we should have finished already. Sometimes we think that other programmers are working faster than us and we need to catch up. The list goes on, and different people will feel pressure from different sources and in different ways.
When we are feeling this pressure to work fast, we often overlook the small refactorings that are required to maintain the code, sometimes with the promise of fixing it later (which I think in the whole history of programming, has never happened). This inoxerably leads to a decline of the code, and the need for large scale refactorings.
Small scale refactorings should be encouraged
Only programmers can make decisions about the code, and the team relies on them to make good small scale refactorings to keep the code healthy and avoid large scale problems.
However, programmers often feel under pressure to work fast, and therefore do not make them.
To allow our people to be their best, we should empower them to make these small scale refactorings, and foster a culture where this is a normal part of day to day work. We should strive to remove both real and perceived pressures.
Conclusion
Creating maintainable code and avoiding large scale refactorings is a collaboration between the whole team. We believe that:
- Only programmers with detailed knowledge of the code can make sensible small scale decisions about it. For example, that a class needs refactoring or a that test should be added.
- Lengthy refactorings are difficult, so we should empower programmers to make the small scale decisions required to avoid them. If large refactorings are required, programmers should recommend a plan of action, which should be discussed with the product manager and team.
- The culture should be such that programmers feel happy making small scale improvements, even when work is behind schedule. This will avoid wasting time down the line, which would ultimately lead to falling further behind.
- It may make sense to cut corners if timescales are very tight (days, or maybe weeks), but issues should be addressed immediately afterwards.
A follow up post details the specific policies and recommendations we make here at RES.
