Questions to ask a developer about legacy code before they leave?

Question

We currently have over 300 web projects that are legacy code, that is kind of spaghetti like based on a modified version of an old framework.

Our one developer that knows these systems best is leaving and I'm the replacement, what are the best questions to ask before they leave? I want to make sure I can support all these bespoke apps

How long until this other developer leaves? Is there any current documentation on these projects? Do you know how to maintain these applications? — Matthew, Aug 30 '16 at 20:22
"What company are you going? Do you know if there are more open positions?" — RMalke, Aug 30 '16 at 20:22
"How often do you fantasize about burning the repository to the ground?" — CHendrix, Aug 30 '16 at 20:23
They have about 1 month left, we have little documentation and nothing is commented — Adrian, Aug 30 '16 at 20:31
Question 1: personal phone number; question 2: his favorite beer. — YSharp, Aug 31 '16 at 05:34

score 2 · Answer 1 · answered Aug 30 '16 at 20:24

It depends on your timeframe, existing documentation (if any), the time span in between projects (300 over 1 year or over 30 years), etc.

Start with the most important apps, the ones that require the most frequent changes and go backwards. Understand those as best you can, have the dev. show you the code and frequent change points.

If its overwhelming see if there is a possibility to agree for the dev. to have a fixed hourly rate that they could charge to assist after they leave in case you need them.

score 2 · Answer 2 · answered Aug 30 '16 at 20:30

You ask for his (her?) contact information. Having them available as a resource (possibly at contractor rates, or possibly over an occasional lunch) is invaluable to keeping legacy systems running.

Regardless of the above, however, get them to map out the system from a high level (including databases accessed and accounts used). You also want to ask for hidden "gotchas" that they are aware of; and take careful notes (these can save a lot of time down the road, if you know what to look out for).

Tulains Córdova · Answer 3 · 2016-08-30T22:06:23.693

Cheatsheets
Common errors and their troubleshooting procedures, workarounds
Prioritized list of pending refactorings
List of error that he has not been able to reproduce
Explanation of permissions an roles
Databases, connections info, admin accounts and their passwords
Version repositories passwords
Explanation of crontab jobs and batch processes
Contact info of business custodians (the non-IT "owners" of the apps business-side)
OS user accounts and password of the crontab/schedule tasks's owner
Contact info of himself/herself
List of problematic modules
Scripts to correct or erase bad inserted data due to app errors
Discussion of the part of the database models that are not obvious or clear (a plotted ER model would be nice) for each database.
Data life-time considerations that may not be well documented, like: trunc this temporal table every N months, or this transactional table's data must me move to an historical database every N years, etc.
Contingengy procedures, including procedures for recovering cluster nodes, promoting an slave node to master and viceversa, etc.
Prioritized list of pending requirements, like modifications, new reports, etc.
Interfaces with other systems or apps.
Dependencies on external APIs

Questions to ask a developer about legacy code before they leave?

3 Answers3