Reverse engineering (RE) is the process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g., a mechanical device, electronic component, or software program) apart and analyzing its workings in detail to be used in maintenance, or to try to make a new device or program that does the same thing without utilizing any physical part of the original.
When I started my career at an Indian public sector telecommunication company, one of the projects that I worked on was a versatile multiplexer. At that time the Indian market was still closed and technological know how from the more developed countries was limited. We did not even have a sample of the multiplexer, just a technical brochure with a feature list of the product. I am not sure if that can be called reverse engineering, but our team did manage to build a working product. By the time it hit the market, I had left the company so I do not know how well it fared. However, I had other brushes with reverse engineering, both successful and not-so-successful.
This was an example of a relatively successful tweaking using reverse engineering. My other endeavors have been less successful. A few years later when I was working to re- engineering a software used for manufacture of sophisticated X- Ray rooms, I was impeded not only by my lack of knowledge of COBOL and the network databases used by the legacy system, but also by the complete lack of documentation by the programmers. After a month of unsuccessful attempts at understanding the source code, I and my lead had to switch over to start top down and understand the business scenarios.
Even on a more recent project when re- engineering an enterprise system for a medical chain, I and my team figured that doing a top down analysis was much more useful to build the new application. Later we were informed by the customer that a number of unsuccessful attempts had been made earlier to re- engineer the system, all of them had started by trying reverse engineer the legacy application.
The major challenges I see with reverse engineering are:
- The source code, where it is available, is often ‘spaghetti’- and very difficult to decrypt
- The cost of reverse engineering is extremely high,and its returns vary from being at best, low to, at worst, unpredictable
- Often because of obsolete technology, the technical skills are hard to find
- Even if the source code is readable, it may be dependent on hard coded data or implicit assumptions that may not be visible to the person trying to reverse engineer the code
- In case of applications, business requirements change so much over a period of time that a lot of the functionality in the code may not even be relevant any longer
A slightly more useful artifact to start the reverse engineering process is the database structure or the ER diagram where it is available. Even there, my experience has been that beyond the list of entities that may help us to understand the system, the details are misleading. The reasons are similar to those listed above- archaic and anachronistic remnants from the past.
To conclude, while reverse engineering sounds very good, and can be successfully used, it is always a procedure of last resort.