The exam that must not need the internet
- The situation
- Schools wanted computer-based exams like the national ones, but their labs have unreliable power and internet, and many of their computers are old.
- What we did
- We put the whole exam system on a server inside the school. It pairs with the cloud once, then sets, runs, marks and releases exams with no connection. When one school said students must be able to start a test with no server reachable at all, a design that had shipped that morning was rolled back the same day and replaced.
- The lesson
- Offline is not a fallback to add later. It has to be the normal case. And when a customer's reality contradicts the design, the design loses.
One thousand one hundred students, one laptop
- The situation
- Before the first school exam day, the in-school server was load-tested with 1,100 simulated students starting at once on an ordinary laptop. On the first run only 811 got through.
- What we did
- Six specific fixes to the server — write locking, worker counts, how background work is launched on Windows, and others — took the same test to zero errors.
- The lesson
- A load test before the customer's big day is cheaper than an apology after it. Test the worst case on the worst machine.
Ten years of runtime, crossed overnight
- The situation
- A school management system in daily use was running on a language runtime and database that were years out of support, at a higher hosting cost than necessary.
- What we did
- About 3,700 files were rewritten automatically so the new runtime behaves exactly as the old one did. A compatibility layer kept twenty-year-old database calls working. The new servers were load-tested with 2,000 logins in a minute. The switch happened in the early hours, with a row-count comparison, health checks for days afterwards, and the old servers kept until the new ones had proved themselves.
- The lesson
- Modernisation is a migration problem, not a rewrite. Keep behaviour identical, prove it under load, and keep the way back open.
Money that checks itself
- The situation
- Several of our systems move other people's money: school fees, tuck-shop wallets, housing instalments, subscriptions.
- What we did
- Every amount is a whole number of kobo. Every movement is a double-entry ledger line. Ledgers add themselves up on a schedule and raise an alarm if they do not balance. Payments are confirmed by asking the provider directly. Collected fees are held for 72 hours before payout, so a parent's mistake can be put right.
- The lesson
- The cheapest control against fraud and error is a system that cannot quietly be wrong.
Every device is a server
- The situation
- A hospital cannot stop registering patients because a cable was unplugged or one computer died.
- What we did
- Every computer runs the same app and can act as the server. One is the hub, one is a standby that takes over, and the rest fall back from cloud to neighbours to their own queue. Before any patient data existed, a simulator replayed hundreds of seeded disasters — outages, crashes, reinstalls — and found fourteen real defects, fixed before a nurse ever saw them.
- The lesson
- If failure is normal, test failure on purpose, by the thousand.
Change one file, change the supplier
- The situation
- Outside services let you down: an upgrade that is never applied, an SMS route that needs manual approval, a mail port blocked by the host.
- What we did
- Every outside service sits behind an adapter. A football data supplier was replaced by writing one new adapter. A marketplace launched with email sign-in when the SMS route stalled. Email moved to a port the host does not block.
- The lesson
- A launch should never wait on a third party. Design so any one of them can be swapped in an afternoon.
A new module the customer can switch off
- The situation
- Schools on an old accounting module needed a better one, but nobody wanted to bet a school's books on a new system.
- What we did
- The new module writes the old tables in the old format, so a school can move to it and move back whenever it likes. Fixes to historical data are add-only, tagged, and proven — with their undo — on a copy before they touch the live books.
- The lesson
- Reversibility is a feature.
The machine that builds is not the machine that runs
- The situation
- Development happens on a Windows laptop; production is Linux. Small differences bit more than once: lock files that would not install, shell commands that damaged special characters, cached settings that ignored new values.
- What we did
- Each surprise became a written rule and a step in the deploy script: regenerate lock files on Linux, reload the runtime on every deploy, test as the real application user and not as an administrator.
- The lesson
- Every surprising failure should end as a rule or a script, so it can only happen once.
Guard the answer key
- The situation
- In an exam system, answers travelling to a student's device before the test is a real risk.
- What we did
- Answer keys are sealed to the device's own key and can only be opened at hand-in. Licences are signed and bound to a device. Content packs are encrypted and signed. A sealed channel lets the apps talk securely even on old PCs that fail normal certificate checks.
- The lesson
- Security has to work on the customer's actual equipment, or it will be switched off.
Tell the user what actually went wrong
- The situation
- A cashier facing the word Error at a till, or a school administrator facing a failed sync, cannot do anything with it.
- What we did
- It is a standing rule in the point-of-sale and exam products that every refusal names the real cause and what to do about it, and that the screen and the server apply the same rule so they can never disagree.
- The lesson
- Good error messages are a support department you do not have to staff.
