Your Results Rest on Rules Written Down Only Inside the Application. Here Is What the Public Record Shows.

A new member of the examination section asks a reasonable question. When a total falls half a mark below a boundary, what does the application do?

Nobody in the room is sure. One colleague thinks it rounds up. Another thinks it depends on the course. The institution’s regulations say what is intended. What the application actually does is in its code, and the developer who wrote that part moved on years ago.

The section has run many cycles on that application, and it has always given the answers the section expected. That is all anyone in the room can say.

What We Found

For this article we went through the public record on examination and results applications, and on how organisations treat old software that still works: one press report from India, one cross-sector survey of IT professionals and one survey of developers.

First, what we did not find: no public account of a college or university that could not say what its own results application does, no figure for how often a results run is late or wrong, and no case at a private college, a school group or a coaching institute. We found nothing from the Middle East on this issue. We did not research how examinations are conducted or what any examination rule requires, and we say nothing about either.

Results processing can go wrong in public, for reasons that are not about old code. A press report described months-long results delays at a public university in India, which it linked to the university’s own software; as reported, the official in charge of examinations gave the pandemic and repeated changes to the examination arrangements as causes. We use this for one point only: results are watched, and a delay is reported. None of this shows that an old system caused any delay. The report does not describe the system as old, and we draw no such cause from it.

Old systems are kept because they work. In one cross-sector survey of 504 US IT professionals, which is not about education, the publisher reports that “62% of organizations still use legacy systems”, and half of those asked said the biggest reason they had not upgraded was that “the current system still works”. The publisher sells related services, and about two thirds of the people asked work in technology or software.

Many developers do not write tests at all. A test is a small automatic check that an application still gives a known answer for a known case. In one survey of 1,720 developers whose main language is PHP, a widely used web language, “32% of developers still don’t write tests at all”. The survey is global, by a firm that makes developer tools, and not about education.

We should be plain about our part before going further. IOanyT does not say whether any rule, or any result, is right. We do not handle, correct, re-issue or vouch for any result, and we do not look back at past ones. We write down what an application does. Your own examination section decides whether that is what was intended.

Our reading, and only that: the regulations say what the rules should be; the code holds what they are. The rules went into the code one at a time, as courses and regulations changed, and few reached a document. An application that has given the expected answers for years is trusted, and what is trusted is not read.

What Waits While the Rules Stay Inside the Application

Our reading is that the cost of rules only the code holds falls on the offices.

Every question is an excavation. A developer spends days in old code, gives an answer in a meeting, and nobody writes it down.

The section is asked about what it cannot see. When a result is queried, the section can say what the regulations intend. It cannot show what the application did without having the code read.

Every change is made without a map. A new course or an amended regulation is fitted into code that few people follow.

The answers are not kept. Knowledge of the application lives in a few people. They did their work well; nobody asked them to write it down.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With Rules Nobody Can Read, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep relying on the application, and answer each question by digging into the code	Few questions arise, and the developer who knows the code is still there	Answers are given once and lost. A rule that works differently from what the section intended is found only when a result is queried
Ask the institution’s own developers to write the rules down	The people who wrote the code are still there and have time to spare	It competes with keeping the application running, and a list written from memory may not be traced to the code or confirmed by the section
Replace the whole application with a packaged examination product	The application is failing in many places, and the institution can carry a long change	Every rule has to be set up again in the new product, and someone still has to say what the old one did. Choosing or installing a packaged product is not our kind of work
Have the application read once, its rules written in plain language and traced to the code, for the section to confirm	The application is used every cycle, and its rules matter	It costs money and the section’s time before anything changes. It will turn up rules nobody can explain, and the decision on each one is the institution’s

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own application, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
Share of the application’s rules written down and confirmed by the section	None; the rules are in the code and in a few people’s memory	Every rule the application applies, in plain language, each confirmed or queried by the section	The section’s sign-off on the specification
Share of the results logic covered by tests that record today’s outputs	None, or a check of the new case only	Every part that must change, covered by tests that record what it produces today	The test report
How long it takes to list what a change altered	It cannot be listed; “it should not have”	The time of one run of the tests	The test run
How long the slowest step takes	Not measured; known as “most of the time”	A target agreed with the section, measured before and after the step is rebuilt	The institution’s own timing

The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for an education body, and none of them is a promise about any result or any date.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your examination and results application, the questions about its rules nobody can answer, and the step that takes the longest. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your institution’s own examination and results application, one it built or had built, and nothing else. Where a supplier holds the code, the institution arranges read-only access to the code with its supplier, as its contract allows; that step is the institution’s, and we do not obtain code from a supplier. It produces a map of the system as it stands, a written specification of what it does, with every rule the application applies written in plain language for your examination section to confirm, a risk register, a cost comparison between keeping and replacing the slowest or most manual step, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Here your own experts are your examination section, and whether a rule is what was intended is its decision. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Here that means two stages at most, each approved on its own. First, we put tests around the parts that must change: tests that record what the application produces today, so that a change which alters an outcome is reported by the tests, and we hand them back to your own team (tests included). Then, only if you approve it, the slowest or most manual step: we replace a system one module at a time while the old one keeps running, and here that is one module only. We never do a single cutover. A traceability matrix links each old function of that step to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What you need to bring: the assessment, bought in whatever way your own rules require; time from your examination section to read each rule and confirm or query it; a named person with the authority to decide what is done about a rule that does not match what was intended; and your own team keeping the application running throughout.

What we do not do: we work only on your institution’s own examination and results application. We do not handle, correct, re-issue or vouch for any result, and we do not say that any rule or result is right. We do not look back at past results or investigate past errors, and we take no part in any dispute about one. We do not run or monitor results processing, and we are not on call at results time; your own team runs the application and the tests. We promise no results on time, and we do not say what any examination rule requires. We do not work inside a packaged examination or student product. We do not ask for student records; any we see in the course of reading the code are not copied or kept. We do not say we are empanelled with any university, board or government, and how each stage is bought is the institution’s own decision. We have no published case of this work for an education body.

What changes for the business:

Role	What they gain
Head of institution	When a result is queried, the institution can show the rule the application applied, in plain words its own examination section has confirmed.
Controller of examinations	The section holds every rule the application applies, in plain language, and has confirmed or queried each one itself.
Registrar	The registry knows how the figures on a transcript or certificate are arrived at, and can say so when asked.
Head of IT	A written record of every rule, each traced to its place in the code, so a question is answered without digging from scratch.
Head of finance	A rule that does not match what the section intended is found in a review of the written record, and not in re-work afterwards.

None of these means any result will be right or on time.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. It describes one public university in India from a press report, without naming it, and its causes as reported were the pandemic and repeated changes to the examination arrangements.	Our part is narrower than that case, and we make no comment on it. For an institution’s own examination and results application, we write down the rules it applies for the examination section to confirm. We do not handle or vouch for results, investigate past delays or run results processing.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before anyone proposes to replace your examination application, we would write down what it does, for your own section to confirm.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →