Tips for Inheriting Legacy Software Code

Photo credit: goran ivos via unsplash
Photo credit: goran ivos via unsplash

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

Stale 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.

Read the rest on!

Author: John Conley III

I am a technology and business consultant who provides state of the art cloud solution design services to rapidly growing and mature organizations using cutting edge technologies. Information Technology Professional with over 20 years of industry experience as a Software Architect/Lead Developer and Project Management Coach using service oriented (SOA/EIB) view of the software development process (Use Case/Story View, Class Design View, Database Design View, and Infrastructure View) and software design (Model-View-Controller based (MVC pattern/framework)). Coached PMs on various aspects of task and resource management and requirements tracking and tracing, and even filled in for PMs. Led teams of varying sizes mainly from the architect viewpoint: translating non-technical requirements into concrete, technical components and work units, identifying and creating reusable frameworks and design patterns, creating skeletal IDE projects with MVC wiring and config files, assigning app tiers or horizontal components to developers, making sure test team members have use cases and other work unit inputs to create an executable test/quality assurance plan, organizing meetings, ensuring enterprise standards and practices are adhered to, enforcing any regulatory and security compliance traceable from requirements/Solution Architecture Documents (SADs) all the way down to core classes in code, and so on Expertise includes designing and developing object-oriented, service/component-based software systems that are robust, high-performance and flexible for multiple platforms. Areas of specialization include Internet (business-to-business and business-to-consumer) e-commerce and workflow using Microsoft.NET technologies (up to current Visual Studio 2010/.Net Framework 4.0, MVC3/Razor View Engine, LINQ), TFS, Sharepoint 2007 (Task Mgmt, Build Script), Commerce Server 2007/2002 (basket and order pipeline), ASP.NET, ADO.NET, C#, Visual C++, Visual Basic.NET) and Java EE/J2EE, service oriented architecture (SOA) and messaging (MSMQ, MQSeries, SAP message handling) and more abstract enterprise service bus (ESB) designs, best patterns and practices, telecommunications and the offline processes of the enterprise. Provide detail estimates on budgets, guided design and development tasks with offshore teams, technical assessments of third party software tools and vendor selections, project/iteration planning and spring product backlogs, and level of effort for statements of work (including for offshore based development teams), including executive summary presentations as needed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: