Software Inheritance: To Rebuild or Not Rebuild?

Businessman using tablet social connection,conceptual image of s

Inheriting software application code, especially complex systems, is no simple task. We frequently find ourselves in front of new clients with existing systems that are unstable or are in need of significant changes. 

This presents a number of challenges and leads to a major decision point: to rebuild or not to rebuild.

Seemingly, any executable code base should save in development costs and calendar time if it can be fixed, adapted, and improved. However, it is better to begin with a healthy dose of skepticism and consider that effort to salvage an uncertain project could be throwing good money at bad.

Clients often present us with largely unfinished or unmaintained code projects that they would like us to evaluate, with questions such as "How long will it take to fix A through Z?" and "Is it worth keeping?"  Establishing any meaningful determination of software quality and development effort cannot be ascertained from casually scanning lines of code. It takes a reasonable understanding of how the software is intended to work and sufficient time working with the project.


Code evaluation misconceptions

Here are some common misunderstandings by both client and consultants about code evaluation:

  1. Myth:  By reviewing code for a few hours, you can get a handle on how long it takes to fully understand what is going on in the code to support it moving forward. 
    Reality:  With the exception of relatively simplistic software, one often has a false sense of comfort unless they go in depth on each branch of code and, even then, there may be interactivity and user expectations that they do not understand.
     
  2. Myth:  By reviewing code, one can tell if the software or developer is "good." 
    Reality:  It may be obvious when code is terrible, but clean, structured, commented, and well organized code is not a reliable indicator that the code is actually correct. The code may be well structured and clearly commented but simply does not work. Additionally, less sophisticated code structures may not be elegant, but sometimes meet the need.
     
  3. Myth:  By reviewing the code alone, one can determine whether or not to keep the code. 
    Reality: Code can be thought of as the logical representation of business rules and activities. Without understanding the business rules, it is not possible to know if the existing code should remain.
     
  4. Myth:  The software is documented and commented, so it should be easy to inherit.
    Reality: First off, can one trust the documentation and has it been updated to the most recent release? If not, it can be worse than no documentation at all. Secondly, detailed documentation (extent and usefulness) is extremely rare; when it is available it can be very helpful, but not always a panacea to the challenges associated with inheriting software.
     
  5. Myth: Once the existing code is inherited by the development team, you can move ahead at full speed. 
    Reality:  Be prepared for quick patches and extra testing time for releases for some time after the initial transfer. Your new development team will be cautiously making changes and monitoring performance.