You have inherited a system nobody left behind any knowledge of, and you have two weeks to produce a plan. Walk me through it.
Answer
Short answer
Spend the first week building an evidence map from money, traffic, incidents and deploys rather than from code, and interviewing the people who touch it with one fixed set of questions.
Legacy systems need discovery before redesign. Good discovery starts with runtime facts: traffic, data stores, batch jobs, owners, incidents, and the paths users actually depend on. Weak legacy systems answers propose a rewrite before discovery has shown what the system is for. Strong legacy systems work turns discovery into a risk map, then uses that map to decide what to stabilise, document, retire, or replace.
Strong legacy systems work also explains how legacy systems became risky, so the team can avoid recreating the same blind spots.
Was this answer helpful?
Likely follow-ups
- Nothing is instrumented and you cannot deploy safely. What is the first change you make?
- Your plan says do not rewrite. How do you hold that line when the team wants to?
- Two weeks in, you find an undocumented nightly job that feeds finance. How does the plan change?
- Who signs off this plan, and what do you need from them to make it real?
Related questions
- The domain expert tells you one thing and the written procedure says another. How do you work out which one the system should follow?hardAlso on discovery5 min
- The customer keeps asking for one thing and everything else you hear says they need something different. What do you do with that in discovery?hardAlso on discovery5 min
- You have twenty-five engineers in three teams and almost every feature needs all three of them. You have been asked to re-cut the organisation. How would you do it, and what does the change itself cost?hardAlso on ownership6 min
- You cannot speak to your users directly because sales owns every account relationship. How do you run discovery?hardAlso on discovery5 min