00 What this is

Ten questions to test whether code reading fits your problem.

Answer ten questions about the systems, evidence and change in front of you. The result says whether code reading fits, what it would need, or why it is the wrong tool.

There are ten questions, and one bounded result is assembled from the answers you select.

The result can fit, name what is needed, or say which tool fits instead.

Scripts off? Every question and each possible reading is set out below as a document.

Scripts are off in this browser, which is fine. Answer on paper or in your head, then find your reading below: the rule for finding it is written at the top of the readings.

01

The questions

Q-01Which of these is closest to the question in front of you?

An auditor or regulator has asked us to trace how a reported figure is produced across the available source path, and to establish whether last year's answer still holds. A resilience standard, CPS 230 here, its equivalents elsewhere, asks us to map what our critical operations depend on. The map we have came from workshops, and I am not certain it is still true. A change is proposed to something shared, and nobody can say with confidence what it would affect. We are moving off a system, and before we can plan the move we have to find out what it actually does. A transaction. We are buying, separating or integrating a business, and part of what changes hands is a body of systems for which only part of the source and operating context is available before the decision. Somebody who carries a critical system in their head is leaving, and the handover plan is a wiki page. Nothing has arrived yet. I am forming a view.

Q-02Think of the figures your organisation reports, the ones somebody signs. Where does the logic that produces them live?

Mostly in one modern transformation tool, which draws its own lineage for the part it runs. Spread across stored procedures, scheduled jobs, ETL packages and views, written over many years, calling each other several layers deep. Partly in code, and partly in spreadsheets and user-built tools that grew up underneath the reported numbers. Mostly inside vendor products, as configuration and code the vendor holds.

Q-03How much relevant logic sits in source that is difficult to inspect?

Examples include long stored procedures, SQL assembled at runtime, and scheduled jobs whose inputs the available documentation leaves open.

A meaningful amount, concentrated in systems the team can name. Some. The awkward parts exist, but the people who wrote them are still here. Very little. The systems are recent, and they are readable.

Q-04How much of what you run is still earning its keep?

Reports nobody opens, feeds with no reader left and jobs that run nightly for a system retired years ago are dead weight, and it is still patched, still audited and still in scope for every migration quote.

Nobody can say. Retiring anything is treated as riskier than keeping it, so almost nothing is retired. There is a list of suspects, and confirming any of it would take work nobody has scheduled. Usage is measured, and anything no longer used gets retired.

Q-05If you were asked today to show one reported figure's path, from the source systems through every transformation to the submitted number, what would that take?

A working group and some weeks, and the answer would be true on the day it was signed. We have the diagram and the memo from last time. The systems have changed since, and I could not say by how much. Our lineage tooling covers part of the path, up to where the older systems begin. We could produce it, current and complete, without convening anyone.

Q-06When a change is proposed for something shared, how do you learn which downstream fields it can reach?

We ask. Emails go out to people who may know, and the approval rests on their replies. We find out afterwards, when a number moves in a downstream report and somebody asks why. The impact is computed from the code before release, and the change record carries it.

Q-07The people who can answer for your oldest systems, the ones colleagues describe as ask him, ask her. How does that list look?

Short, and shortening. Some of it retires or leaves inside the next couple of years. Short, but stable for now. The dependency sits on our risk register with a named owner. The knowledge is written down, the documents are current, and a new arrival could work from them.

Q-08Take a term your organisation reports on: customer, account, exposure, premium. Does it mean the same thing in every system that computes it?

Nobody here knows, and I would not bet on it. We know the definitions differ. Reconciling them is somebody's job, every cycle. One definition, agreed, enforced, and tied to the code that implements it.

Q-09Is a model or an agent going to be put over these systems?

A model reads what it is given, and what it is given about these systems is either a record of what the code establishes or the names and documents around it.

Yes. It is planned or under way, and what it is given about these systems has still to be decided. It has been raised, and nothing is settled No. Nothing of that kind is in front of us.

Q-10Last one, and it decides more than any other. The systems this question touches: could you show a reader the code?

Yes. It is ours, in repositories and on servers we control, and access is ours to grant. Mostly ours. There are vendor products in the path whose internals sit with the vendor. Mostly theirs. The important parts sit inside vendor or SaaS products, and we hold configuration at most.

02

The reading

Nothing you select leaves this page.

The mail carries this reading, word for word, in your own mail client. Nothing is sent by this page.

The reading is composed on this page, from your answers and nothing else. Change an answer and press the button again, and it recomposes.

03 The readings

The readings, in full

Scripts compose one of these three short readings from your answers. All three are visible here when scripts are unavailable.

Your answers point to a code-reading problem.

The auditor's request

A source reading establishes a dated path from figure to producing code.

The dependency map under CPS 230

Named source tests the dependency map against the code itself.

The change with an unknown affected set

A pre-release source reading names each path the change can reach.

The system being moved

Named source versions support comparison before and after cutover.

The systems changing hands

Supplied source is read before signing, and the rest becomes a named post-close item.

The person leaving

Source can be read while the expert can still disagree with it.

Forming a view

The review covers source-linked results and their stated assumptions.

What a first pass covers

A first pass takes one question and one system's source, and the result sets the next step.

The vendor products in your path

The reading covers what you supply and names the vendor source it was not given.

What a reading gives a model

It is given the record, in which a reading has established from the source what depends on what, graded each relationship by the evidence the code could give, and refused where the evidence runs out while keeping the reason. No model is involved in producing it. A model holding the record has the map as the code established it, with the grade on each relationship and the refusals with their reasons, and without it the model infers those relationships from names and documentation. What the model does with the record, and whether it is fit to be put over these systems, stays with your team and its risk function.

What to do next

The next step is one question and its source.

Your answers say the evidence you already hold is enough, for now.

Answer it with what you hold

Your current evidence appears sufficient, and the measure to retain is its production time.

Departure, on your answers

Your documents appear to carry the system map, so the handover can retain judgement and compare them with source.

A view, formed

Your logic is readable and your evidence is current, and a change to either is the point to reassess.

The standard to hold it to as it grows

The standard is source-linked evidence, with any unread part named as such.

What to do next

The evidence you already hold is the right answer for now.

Your answers say code reading is the wrong tool for this problem.

Where the source sits decides it

The relevant source sits with the vendor, so code reading is the wrong tool for that part, and the vendor process is right.

The shape of answer that fits

Vendor evidence covers the product, and a separate assessment fits the configuration and integration code whose source you hold.

If some of that source is yours

Assess that part separately when its source is supplied.