Incremental Software Development for Large Scale Refactorings
In the end, incremental software development techniques are almost always the safest way to refactor. Here is why.
My previous post was about the badass developer attitude. More specifically, how it can buy sponsorship for large scale refactorings. Unfortunately, attitude is not enough. We also need to be able to deliver in a way that builds trust with the business. Most of all, business is scared of the tunnel effect. Incremental software development techniques allows to deliver large scale refactoring step by step. Not only that, but it also allows to do so alongside business features. That’s how badass developers walk their talk and gain the business people’s trust.
This is the fifth post in a series about how to get sponsorship for large scale refactoring. If you haven’t, I encourage you to start from the beginning.
Why does incremental software development matter ?
A short story
A few years ago, I joined a team whose work involved a Domain Specific Language and a parser. The parser had grown in an ad-hoc way for a few years, and was now both very brittle and difficult to extend. We knew the way to go was to adopt a more solid parsing approach. We wanted to migrate to ANTLR and a multi pass parser.
As always, the business was very pushy for new features. There was no way we could have stoped everything for a full parser re-write. We explained to them that some of their features would be impossible to write without the new parser. We suggested that we work on migrating the parser as a background technical Epic. We did so using incremental software development techniques.
It took us a few months to migrate the parser. Meanwhile, we kept the software in a releasable state. This allowed us to validate our progress on the refactoring. We could continue to release features. We were able to share our progress on the refactoring with the business people. They were very happy with the way we did this refactoring. In fact, it set a standard about how to prepare the software for big features later on.
The real problems
To understand why incremental software development works, let’s understand the alternatives’ problems. The main alternative it to do the refactoring in one massive task. This kind of initiative screams “Tunnel effect waiting to happen” ! The tunnel effect scares business people for 3 reasons :
- Because they don’t know how much money they’ll need to put in the tunnel to get out of it
- Because they don’t know when they’ll get the other features which they are also waiting for
- To be blocked in the tunnel if something unexpected and important comes along
Delivering a large scale refactoring with incremental software development fixes these 3 points.
- Every commit is a step forward while keeping the system in a releasable state. If ever something unexpected comes along, we can pause the refactoring for a while. (point 3)
- Not all the team has to work on refactoring at the same time. Working on the refactoring does not block the delivery of other features. (point 2)
- Finally, after working on a refactoring for a while, it becomes easier to have an idea of how long it will take. (point 1)
💡 Incremental software development fixes the business people’s fear of refactoring tunnel.
It is true that performing the refactoring in one team-wide batch would be more efficient. It would reduce the overall Work In Progress and get it done quicker. Unfortunately, it’s also a lot more scary for business people !
Incremental Software Development techniques
Like any skills, we can learn these techniques. Some are easy, and we can learn them from books. Others are more difficult and are usually learned through hard won experience. They can also be learned from a veteran developer in your team who’s been through all this already. If you aren’t or don’t have a veteran around, we can still manage. Deliberate practice is a great way to learn almost anything. Coding dojos are the thing here (I’ll write more about this later).
Once we master these skills, a lot of things change. First, we can do refactoring without harming our relationship with business people. Second, it builds enough self confidence among developers to negotiate with business people. This in itself, makes us more credible in their eyes. As a result, they are more likely to compromise on prioritizing refactoring.
💡 Mastering incremental software development builds self-confidence for developers.
To be continued
This was the fifth post about how to get sponsorship for large scale refactoring. In the next posts, I’ll deal headlong with the actual techniques. How to get bandwidth ? How to work in baby steps ? How to track the progress ? How to deal with the large scale ? Finally how to go further ? As you can see, there is still a lot to come, so continue reading !
Leave a comment