Today, reengineering a software system is relevant for many companies. It can be provided either by developers on site, by an outsourcing company, or by a distributed team. This type of team may include developers from both sites.
I would like to give some advice to outsourcing companies. My thoughts could be useful for both types of teams – whether an outsourcing team provides the whole reengineering project or only some of its tasks.
So, what can we do to make the project successful and the product owner satisfied with your work?
- Coordinate all your steps with the customer (CTO or Tech Lead)
This approach helps you avoid mistakes and share responsibility with your customer. Don’t forget that only the customer knows exactly what result is needed and what costs can be spent. That’s why, when deciding whether reengineering is required, planning the project stages or providing any changes to the plan – your customer should approve all important steps.
- Select prospective technologies
This is essential for any site that analyzes the system and prepares a list of suggested technologies. Select technologies that give maximum potential for further development and maintenance, but don’t chase the latest fad. Technologies you suggest should have met approbation and approval in other projects.
- Don’t hesitate to suggest your ideas
You work with the system, you see it from the inside and you also know the technologies and their features. You can have valuable ideas about how using some feature can improve the system, ease development or establish options for further enhancements. Even if the customer doesn’t accept your ideas, don’t give up, just be more persistent next time.
- Compare risks and profits
When suggesting any changes, always be aware of the possible risks and the expected profits. Making a change is worthwhile only if profits exceed risks. This message concerns the whole reengineering process as well. At some point, the risk of regression will reduce the profits from the enhancements and if this happens, reengineering should be halted.
- Include tools for metrics and profiling
As the revamped software system ages, its efficiency may fall. If tools for metrics and profiling are included in the software system, actual performance and stability indicators of the system can be monitored. This is important in both cases – when reengineering a legacy software system and when developing a new one.
- Test the revamped system on all levels
A full testing strategy should include all the testing phases, test types, project environments, roles and responsibilities, and the common tools used. Many legacy systems have no tests; in addition, any software changes can cause new bugs. That’s why every change requires a regression test. Also, always test persistent problems even if the changes don’t concern this part of the system.
- Migrating clients to the new system means more than just migrating data
Migrating clients may become a fussy thing. In addition to migrating data, you (or the product owner) should teach them how to work with the modernized system. Here a major problem may arise: clients may dislike the changes, overlooking the benefits and overstating the limitations of the revamped software. That’s why the migration plan should be customized for every client and should be understandable and acceptable.
Sure, these are not the only principles useful for a reengineering project. Moreover, most of them are useful not only for this type of project. But what really highlights reengineering is that this is a process of providing enhancements, without changing the system’s functionality. Reengineering makes the system more efficient, reduces maintenance costs and expands the potential for further development.
