At one point or other, a software developer will be tasked with inheriting another developer’s code. Less experienced developers will not have a clue what’s in store for them, and more experienced developers already know it’s like playing Russian roulette. Ideally, the prior developer did a reasonably good job with writing clean code (not perfect, but clean) and hopefully some inline comments clarifying the more complex, mission critical parts of the solution.
The level of tech debt the inheritors encounter will depend in large part on the age of the code base, which is a key factor in what’s called software rot. Software rot is the idea that, like any other tangible product, software decays over time. The rate of decay accelerates if the code is not continuously updated and deployed. This means there are two categories of inherited code:
Fresh code will often have the latest libraries and frameworks in place. Hopefully, they follow the latest best practices for mobile and web development. Code written in the modern era of MVC and microservices will likely be reasonably clean enough to understand without much documentation. Stale code, on the other hand, runs the risk of being out of touch with the latest best practices. Code written, say, 15 years ago will have big monolithic services (early SOA era) and some fat UI clients. Infrequently updated code are not as bad as code that has not been updated in a decade or longer. Following DevOps processes ensures the code stays fresh and is easier to inherit.
Code Inheritance Tasks
There are three tasks code inheritors will encounter in adapting legacy code to an environment they are comfortable managing:
· Schedule knowledge transfer sessions
· Interview users and business analysts
· Ensure the code is under continuous source control
Schedule knowledge transfer sessions
If the original development team is available, I schedule knowledge transfer sessions. Don’t go overboard scheduling daily two-hour sessions stretched over two weeks. That’s overkill. Take time to first review the code, making a list of questions you might have. Delineate the questions along the lines of:
Model View Controller (MVC) areas
SaaS-PaaS-IaaS tiers (Cloud context)
Mobile and Web apps tend to be broken up into code in the Model, View (UI), and Controller. If the code is not cleanly partitioned in this manner, then it might be useful to create a class diagram or some kind of diagram the maps the existing code logic to something you’re more familiar with so that your questions provide good code coverage. Be sure to also ask questions about log files and frameworks, config files and any environment configuration problems the legacy developers ran into.
Related questions to ask legacy code developers when they are available for knowledge transfer:
What version control system and build process did they use, and if none, how did they manage code builds from the pull request phase to deployment?
What code deployment strategies worked best for the code?
Kanban boards would be quite helpful for the process of inheriting code. If original development team is not available, let’s hope that the code is reasonably well documented either in inline code comments, cleanly named classes and services, and/or external documentation.
Interview users and business analysts
Along the same lines as interviewing the legacy code developers, schedule time talk to the users and any business analysts who worked with the original development team. Ask them what they like about the code and what areas of the code need improving. Often, through no fault of anyone necessarily, there are gaps between the stories and features documented in the user requirements and the support for them in code. By interviewing subject matter experts, you can quickly identify those gaps and maybe ask the original developers for their side of the story, if available. If not, keep track of your gap analysis as either stories or bugs/defects in your source control system. Identifying code that can be salvaged and factored is very likely at this point.
Ensure the code is under continuous source control
If the code is already under source control, great. If not, a plan needs to be put in place to move to a source code and build management system such as one that supports continuous integration-continuous delivery (DevOps based systems are great for this). Once the system is in place, work with the QA team to decide on a deployment strategy. If the legacy code will be kept intact without changes, the deployment should be pretty straightforward since you can simply follow a DevOps strategy that you’re comfortable with. However, if much of the code needs to be refactored or wrapped in a façade component or service, then a Blue green deployment strategy might be suitable so that you can phase out dependencies on the changed code and phase in the new code. There are other code deployment strategies that are available that might offer better alternatives.
Hopefully these tips provide some ideas for more effectively inheriting software code regardless if the original developer is available or not. Remember to determine if the code is fresh (has been continuously deployed) or stale (has not been deployed in an extended period of time). If the code is stale, it will subject to accelerated software decay, so create a DevOps pipeline to get it under source control and managed under a CI CD process. Schedule a reasonable number of knowledge transfer sessions with as many original stakeholders as is available. Any problems in carrying out this knowledge transfer has to be identified as a schedule risk to the overall project, something that project managers and executive stakeholders need to be aware of. Categorize ineffectively documented code along the lines of modern architecture partitions, such as MVC (microservices and web/mobile apps) or the familiar SaaS-PaaS-IaaS tiers (for full stack cloud solutions).
About the Author
John Conley is an independent technology consultant for Samsona Software as well as a freelance writer based in Dallas, TX.