Can you understand an unfamiliar system in five days?

When I start working with a new system, one question comes up regularly:

What can you actually establish about this in five to ten working days?

It is a fair question. Knowledge of a complex system that has been running for years often takes months or years to build up. Meanwhile business requirements change, developers come and go, new integrations are added, and the system carries decisions nobody remembers the reasons for.

A short system diagnosis is not magic, and it is not a substitute for a full review.

Its purpose is different: to give a usable, evidence-based picture in a short time of what is happening in the system, where the most important risks are, and which next step is actually worth taking.

I do not start with the code

One of the most common misconceptions is that a system diagnosis equals reading the code.

The code matters, of course. But on its own it does not tell you which parts of the system cause real business problems.

So in the first conversations the most important question is not which framework was used, or how many lines the codebase has.

I try to understand:

• what the system is used for;
• who relies on it day to day;
• which processes are business-critical;
• what has broken or slowed down recently;
• which changes the team avoids;
• which failures keep coming back;
• what decision management is facing right now.

I have seen systems that did not look particularly modern at first glance, yet served the business reliably.

Other times we found operational risks inside a seemingly up-to-date architecture that mattered far more than any technology choice.

For a diagnosis, what counts is how the system behaves in real use.

In the first days I try to assemble the story

An old system rarely has a single story.

Developers see something different from the operators. Management perceives delivery slowing down, while customer support sees the consequences of the same thing as incorrect data or drawn-out cases.

In the first days I try to put these perspectives side by side.

I look at how a business requirement arrives, how it reaches development, how it gets to production, and how it becomes apparent when something is not working properly.

At this point problems often surface that do not look serious on their own:

• a manual step in the release process;
• a poorly documented integration;
• a rarely used but business-critical process;
• a database operation that only slows down under heavier load;
• an alert that fires so often that everyone ignores it.

Together these make up how the system actually works.

What I examine during a short diagnosis

Not every system can be examined with the same template, but there are typically five areas I focus on.

1. How the system is put together

What are the main components? How do they communicate? Where are the tight dependencies? Which parts change often, and which has nobody touched in years?

The goal is not detailed documentation of every class and endpoint. It is to understand where complexity and change risk are concentrated.

2. The critical business processes

The severity of a technical problem is not determined by its place in the code.

A tiny component can be business-critical if without it you cannot invoice, serve a customer or transfer data.

So I always try to connect parts of the system to the business. Which failure is an inconvenience, and which one actually stops the company from operating?

3. The development and release process

I look at how a change travels from idea to production.

Where is the waiting? What happens automatically, and what is done by hand? Which tests run? How safely can a bad release be rolled back?

This is often the point where it becomes visible whether the slowdown has a direct technical cause, or whether the problem is in the process.

4. Operations and observability

You should not learn about the state of a system only once it is failing.

I look at what logs, metrics and alerts exist, how well the cause of an incident can be reconstructed, and how anyone would know whether users are really experiencing what the team assumes.

If a failure only becomes visible through a customer complaint, that finding matters in itself.

5. The team's knowledge and ways of working

A system is not held up by its code alone. It matters just as much who understands it, who can change it, and who can operate it safely.

I look at how concentrated the knowledge is in a few people, how traceable earlier decisions are, and how easy it is for a new developer to get involved.

This is not an assessment of individuals. The point is to understand how dependent the system is on particular people being there.

What the diagnosis hands over

A good diagnosis does not end with a long list of defects.

What management and the team usually need is:

• a short summary in plain language;
• the most important technical and operational risks;
• the business impact of those risks;
• the dependencies between the problems;
• proposed 30/60/90-day next steps;
• an estimate of the effort required;
• a note on what is not worth changing right now.

That last point is often especially important.

A diagnosis is not valuable because it finds as many problems as possible. It is valuable because it helps separate the urgent from the important from the currently negligible.

What cannot be established in five days

A short diagnosis has clear limits.

It will not find every defect. It will not accurately predict every future load problem. It does not replace longer operational experience, and it must not give false certainty on questions where the data is still missing.

A good diagnosis makes those uncertainties visible too.

It shows what we know with confidence, what still needs verifying, and which questions are worth answering in the next phase.

The goal is not to understand the whole system

In five to ten days you do not need to understand every detail of the system.

What you need to understand is:

• what is currently holding back progress;
• which risks threaten business operations;
• which problems can be solved with a small intervention;
• when a larger modernisation would be justified;
• and what the next responsible decision should be.

That is why I do not start the work with what should be built.

First I try to understand what is happening now, why it happens that way, and how big a change is needed for the system to support the business reliably again.

A system diagnosis is not the final answer to every technology question. But it is a good starting point for making the next decision on a shared, evidenced picture rather than on assumptions.