One of the most important practices when building software is iterative development. It is key to delivering successful projects on schedule and an invaluable part of running an effective Scrum process. The idea is associated with building out new products, but it is equally important when rebuilding existing ones that you may encounter during legacy modernization projects.
What is iterative development?
Iterative development is simple in its goal, but can be tough to implement. The core idea is that you are continually delivering small features that provide value to the business. These pieces may not even be part of the final project, but they do get you moving in the right direction.
A common example used to explain this concept is building a car. You might think a car would be built by first constructing the engine, then the chassis, wheels, and so on, until you have a running car. However, this is not an iterative approach.
If you wanted to build this iteratively, you’d first build a push scooter. Then you’d build a bike, a motorcycle, etc., until you had a working car. Each completed unit would be a mode of transportation that could provide some of the value a car might, albeit not quite as comprehensively.
Why build iteratively?
Now this is where you might be wondering why this approach has value. After all, you still end up with a car, and you might even take the same number of steps. But there is one crucial piece missing in the first approach, an opportunity to get feedback as you go.
You can’t give someone an engine, and then ask how much it helps their commute. You are stuck waiting until the final product before you can gather any feedback or test any part of the process.
If you deliver them a scooter after the first iteration, you can tell them to ride it to work. While it might not be exactly what they were hoping for, you can still gain valuable insight. You can learn what kind of terrain they ride over, how far they travel, and what weather conditions they run into. All of that feedback will help with the next iteration.
By the time you deliver a car, hopefully, you’ve incorporated everything you’ve learned. That’s opposed to the first approach, where you don’t get that information until the car is already built.
Applying this to legacy modernization
Most of the time, you think of iterative development when talking about building something new. However, an area where it is often overlooked is when working on updating or replacing an existing system.
It is easy to look at an existing system and spot the ways it could have been built better. After all, you do have the benefit of seeing the consequences of every decision. You know the performance bottlenecks of the system and the legacy technologies causing those bottlenecks.
Why not just build it better?
It is tempting to take these lessons and apply them to the replacement, building it the right way this time. Maybe instead of using a SQL database full of transactions, this time you use events. Instead of using a stored procedure with all the business logic, you write application code to achieve the same results.
While these decisions would undoubtedly have made the existing system better, they run the risk of missing the bigger opportunity. This approach avoids asking the more important question: Does this solution still make sense for the business?
How do you rebuild iteratively?
When you rebuild iteratively, you can re-evaluate how best to solve the actual problems the business faces. You can still improve the things that do need to be carried over, but can also remove the things that are no longer needed.
Most legacy systems are still in use because they are the only way to achieve business goals, but that doesn’t mean that they are the best way to achieve those goals. More often than not, a system is not even being used for the same reason it was initially designed.
Over time, these systems have had new features and functionality piled on top of what was already there. Maybe the page loads slow because the tech stack is outdated, or maybe it loads more data then it needs. Sometimes you won’t know until you re-evaluate why the page exists to begin with.
Treat it like a new project.
By choosing the smallest possible piece to rebuild first, you can figure out what parts of the original design are still relevant, and what can be left behind. Having an existing project to reference will make this easier, but try to avoid solving the problems it has today.
Instead, figure out why it’s still in use today. Once you know, you can figure out the best way to achieve that goal, even if the route you take is different. This can be a tough sell for the old system’s users, which is why the small usable pieces are so important.
Show these people who are living in the legacy system that you are giving them a better way to get what they want, even if it is only in one case. Once you start to build that trust, you can start to show them all the other ways to solve their problems.
By the time you are finished, you may end up with a project that does not even resemble the system it was built to replace.
It’s all about feedback.
The common theme throughout these approaches, regardless of the type of project, is a reliable way to gain consistent user feedback. Whether you are building a new project or modernizing an existing one. The only way to ensure you build the right thing is to get something useful in front of a user as soon as possible.
No amount of planning, research, or design can replace the feedback you get from putting the product in the hands of people and seeing how they use it.