We have many legacy applications which are 10-15 years old. The readability of the code is also challenging and many applications depend on other subsystems too. Documentation on these applications are not readily available, and are often not up to date. SME availability is also poor, and some SME's have left the company. Changing code in these applications without having deep domain information is also challenging, and we tend to miss some scenarios. Business folks are also new.


With all of these challenges, how can team members learn the domain quickly and effectively?

1 Answer 1



[H]ow can team members learn the domain quickly and effectively?

There is no short-cut to mastering a legacy code base or knowledge domain. However, your organization can certainly choose to ensure that training and exploratory testing are made project priorities for the new team. The technical debt must be treated as a visible cost to the business, and paying down the debt should be charged against the current project as a cost of doing business.

Technical Debt Doesn't Vanish

Your legacy project has a great deal of technical debt, and your organization has spent more than a decade failing to invest in documentation, knowledge transfer, cross-functional training, and effective hand-offs of its project deliverables. There is no silver bullet that will make this vast technical debt vanish; it must be treated as a visible cost to the business and acknowledged as an impediment to the current project.

Engineering Issues: Legacy Code and Exploratory Testing

I strongly recommend having the whole team, including the project managers, read some books on managing legacy code and performing exploratory testing. You might start with:

These books will give you at least a general idea of the engineering issues involved when you inherit a legacy code base, but very few books really talk about how to integrate these issues into the schedule or project plan of a maintenance project like yours. Read on for some specific advice about that.

Project Management Issues: How to Pay Down 15 Years of Technical Debt

You've already identified a number of areas of technical debt, including:

  • Inadequate system documentation.
  • Non self-documenting code.
  • Brittle code with poor separation of concerns.
  • Brain drain caused by poor staff retention or improper project hand-offs.

There's no quick fix for any of these things. However, all of these things can be effectively addressed by making the debt visible to the organization, and explicitly allocating resources to pay down the debt. Specifically:

  1. Explicitly include exploratory testing to your project plan.
  2. Explicitly add self-documenting unit testing to your project plan.
  3. Explicitly add user- and administrator-level documentation tasks to your project plan.
  4. Explicitly add team members with testing and technical writing skills to your project team.
  5. Explicitly include any subject matter experts that remain with the company into your project plan, either in a training or team-participation capacity.
  6. Explicitly add enough time to your schedule to perform necessary refactorings as you place the code base under test and disentangle your subsystems.

This is by no means an exhaustive list, but it should get you started. The important things are to ensure that the cost of all the accumulated technical debt is made visible to the organization, and all necessary mitigation measures are explicitly included in the team's process.

  • 1
    Joined my SO account with this subdomain just to upvote this awesome answer that every manager should read and internalize.
    – TonyG
    Jun 11, 2015 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.