“What happens when applying changes to a project in which all the original developers have left?”
“My solution is fully functional, but every time I want to apply a change the cost is too high. What can I do?”
“How can we improve the way we manage our legacy applications?”
All these topics and several other situations are common nowadays in the industry as solutions that have been built upon a lot of organizations’ effort and investment.
Our customers often remark that every time they want to introduce a change in a legacy application they receive pushback from their developers. Sometimes the intended changes cause so much work that the company would be better off starting an entirely new project from scratch rather than trying to fix the problem with constant upgrades.
Is there anything we can do with all the value that has already been added to a given piece of software? Is there any process we can apply in order to take advantage of the experience acquired after all that effort?
Yes, there is, it’s called Software Archaeology.
After years of helping our clients recover the control over their applications, here at Globant we have developed a process to guarantee that all the value previously added is going to be taken into account in the evolved solution. Our solutions adapt to the new business requirements and market trends in order to meet customer’s existing and future needs.
Software Archaeology is the systematic study of past software systems by the recovery and examination of remaining material evidence, such as code, tests and design documentation among others. In this way, we can take control of any software solution, in any status, at any moment, without a long, hard or expensive process.
Tracing a parallelism with traditional archaeology, we have divided our process into four stages that ensure we cover all aspects necessary for success in this journey:
- Field Survey: Software Archeologists have the first contact with any scenario when they look for evidence in order to understand the application culture. They do this by playing with the application non-intrusively, executing it, testing it, and seeing the results. They also locate places of interest and learn from their observations.
- Excavation: Our archeologists get deep into code and functionalities in order to obtain the complete knowledge of the systemic context. We review the source code and add logs in order to understanding the overall architecture. Modifying little pieces of code allows us to understand how the results change.
- Analysis: We study the excavation results. This helps us produce a development plan along with a recommended approach to follow.
- Development: The Development Team has a full understanding of the systemic context and works on the application like the original team.
Your legacy software has not reached the end of its life. There is a process you can apply to remove the “legacy” term from that sentence and to make your solution into what you need simply by investing in what’s required without wasting all that has been learned in the construction of former versions.
And what about that guy that told us “all of this is wrong, we should start all over again and redo everything from scratch?” Was he wrong? Most probably what is wrong here is the approach. It is just a matter of different opinions, and we understand this as what we call a “technology ethnocentrism” problem. Each architect has his or her own truths, sometimes perhaps thinking that others are wrong even at the cost of not being able to see what the real problem is. Our Software Archaeologist understands the problem from the culture being studied through the evidences, not from his or her personal technological beliefs.
Your legacy software is your baseline, and your ideal solution is its evolution.by