Software refactoring is a survival need
You wake up in a sweat. It is the middle of the night. What happened?
You were dreaming. Nightmaring, to be precise. Your project, your baby, your life for the past months, totally crashed. Developers quitting, your excellent features impossible to deliver, your clients unhappy.
What happened? What did you miss?
I’ll tell you what. You missed the PAINFUL REFACTORING of DEATH.
A little software theory
When a project starts, nobody ever really knows what it will be. It is part of our job, as developers, to learn as we go along, remake, rearrange, learn and improve.
It is therefore logical to see that a software project, any project, goes through 3 unskippable phases:
- Quick-started version
- The Painful Refactoring of Death
- Maturity
First, you want something minimalist that will be useful as quickly as possible, so that you don’t drown before launch. Project managers are under too much pressure. Developers must merge yesterday. QA people wonder why they’re even here and cry in their sleep because you need to deliver before you get any chance to test.
Debt is accumulated, until the project reaches this critical tipping point.
At this stage, any software faces a decision: refactor, or die.
How to spot it in time
If you’re lucky, you are already running in production.
To achieve this, you have accumulated so much technical debt that most of the developers’ time is dedicated to workarounds and patches.
Look for the clues:
- Your team double their estimation for any new feature of bug fix
- Nobody ever trusts what they merge anymore. A single line may very well break the entire system. When you say “test coverage”, everyone looks out the window whistling
- Newcomers are told to never touch this central part of the code, nor that one, and maybe not this one either. Onboarding is difficult.
- People start to quit, as working on this is just too painful
How to survive it
First and foremost, the team will know. They will complain and tell you.
In case you don’t want to listen or they all left already, here are some ideas on where to pay your debt first:
- Test coverage. Make sure that what works keeps working. Add unit tests, integration tests, end-to-end suites, and be clever about it. Testing is a craft and some people are very good at it. Never, please, never consider that testing is just plain common sense and could be done by anyone with a brain; there is more.
- Simplicity. You really like this fancy feature that nobody ever uses: either cut it out or make it useful. You like having 45 ways of doing one thing. Keep only the best.
- Bring back consistency. Technical interests on debt usually include some inconsistencies. We try one way, try another, improve the first, merge the two and after 6 or 7 tries we have something we like. But we also have 7 different versions out there.
- Documentation. While you are writing documentation, you will see what lacks in the above ideas. If you cannot describe what a thing does in one sentence, then that thing needs rework: get rid, split, simplify,…
How to avoid it altogether
You are starting a new project and want to avoid this difficult phase? Invest.
Most projects cannot afford such a luxury. Making clean things requires time and money you don’t have when you start.
That said, keep in mind that the Painful Refactoring will befall you, whether you want it or not, generally at the least practical moment. Make room for it, prepare for it, give your teams room for continuous improvement. Listen to their ideas and complaints.
Conclusion
Making software means trying things and improving them, then coming back to make them better. Refactoring does not bring direct value to the clients — it brings sanity to the teams, quality to the product, stability and then faster development and easier maintenance.
Go back to sleep but don’t forget when you wake up: this is your last chance to act.
