School Financial Software, a Decade Old and Still Adding Up

One of the largest public school districts in the country — more than 160,000 students, close to 200 schools, over 10,000 employees including more than 10,600 classroom teachers, an operating budget north of $1.9 billion — ran the formula that decided how much money and how many staff positions each of those schools got from a single file of Perl.

The file worked. It did the math correctly, year after year. But it had one output: flat files someone then had to open and read. There was no interface, no way for the district's own finance team to change an input themselves, and — this is the part that eventually forced the issue — only one person alive who could reliably change the code without breaking something else somewhere in it. That person was the original developer, and by the time the district decided it needed to modernize, he had just retired.

That's the setup this engagement walked into: a financially correct, functionally frozen system, with its only expert gone.

The mandate

The district brought in a solo contractor — no team, no firm, just one person — through a project manager who relayed what the finance team actually needed. The finance team was the real client here; they were the ones who'd have to live with whatever got built, and they were the ones who, until then, had never been able to touch their own inputs without asking someone else to change code.

The mandate was direct: make the system robust enough that one retirement wouldn't threaten it again, make it usable enough that finance staff could run it themselves, and — non-negotiable, for a system that moves real dollars to real schools — don't let any of that come at the cost of the numbers being right.

What got built

The replacement was a structured web application, not a bigger, better version of the same flat-file approach. It computed both dollar allocations and staff-position allocations — the actual number of teaching and staff positions a school was funded to fill — to every school, by formula, including the Months-of-Employment calculation nested inside it: the staffing-side math that feeds how those position allocations get funded.

The formula itself was weighted by grade band — a kindergarten seat and a high-school seat don't draw the same allocation — and it accounted for school-specific exceptions the district's own policy required: particular schools that, for one funding reason or another, didn't follow the standard formula. Those exceptions had lived as tribal knowledge in the old system. In the new one, they were built directly into the calculation engine, the same one every other school's numbers ran through.

The application pulled in the membership data — enrollment counts, by school, by grade, updated as the school year moved — that the formulas actually run against, and it connected out to the district's Oracle E-Business Suite platform, the system of record for the district's actual finances, so the numbers the application produced could be reconciled against what the district's books actually showed. It generated the PDF and spreadsheet reports the finance team needed to hand upward and outward. And it served two audiences from one codebase: an administrative interface for the central finance office, and a separate, permissioned interface schools' own staff could use to see their own numbers — something the old flat-file system had never offered anyone.

Multiple years of school-year data lived in the system side by side, so a finance staffer could look back across years, not just at the current one — a basic capability the Perl-and-flat-files predecessor had never had a way to offer.

How the numbers stayed right

None of that mattered if the dollar and position figures the new system produced didn't match what the formula was actually supposed to produce. The old system's only output had been flat files — and that turned out to be the asset that made real verification possible: every dollar and position figure the legacy system had ever produced was sitting right there, in writing, to check the new system against. The base allocation, the grade weighting, the Months-of-Employment layer, the school-specific exceptions — each ran against real membership data, and its output was compared directly against the legacy system's own flat-file output, case by case, across years and schools, alongside the figures the finance team already knew and trusted. Nothing shipped until it matched.

That's genuine parity verification, output checked against output, not a spot check or a sign-off on faith. The method looked different than it would today: we now run this kind of comparison through an automated harness, re-run independently by a separate reviewer. In 2014, the comparison was manual — the new system's numbers held up against the old system's numbers, row by row, until they agreed. The method and the era are different. The rigor isn't.

What ran for a decade

The system went into production in 2014 and ran the district's fund-allocation process — every school, every year, dollars and positions both — for roughly the next ten years. The finance team used it to manage their own inputs directly, the thing the old system had never let them do. The calculations it produced then are the same calculations it's still capable of producing today: the formula logic held.

That's the actual headline here, and it's proof of a different kind than the parity work at cutover alone could offer. It's ten years of a $1.9-billion-budget district's own finance staff trusting a formula engine one contractor built, verified against the old system, and handed over — and it holding up, allocation after allocation, school year after school year, with no one having to go find the one person who understood it.

Reliable isn't the same as maintenance-free

A system that runs correctly for a decade is a genuine achievement — and it's worth pushing the car metaphor further than "don't skip the oil change." An oil change isn't a correction you make once, ten years in; it's routine, on a schedule, precisely because a car that's running beautifully still needs it — and skipping it doesn't show up right away. Software ages the same way, for a reason a car doesn't have to deal with: the ground underneath it keeps moving. Languages, libraries, packages, platforms — all of it shifts out from under an application on its own timeline, often for security reasons, whether or not the application's own logic ever changes.

That's why "working and finished" is the wrong way to think about software. Staying healthy is continuous upkeep, not a rebuild you get around to once the risk has already piled up. That's not a knock on the 2014 build, or on any build that holds up this long — building something that lasts, and knowing what it takes to keep it that way, are the same discipline.

What this says about legacy financial systems generally

The easy story to tell about old code is that it's a liability the day it's written and everyone just hasn't noticed yet. This one doesn't fit that story. A single contractor, working alone against a financially correct but functionally frozen predecessor, built a system that a large public school district's finance team ran, trusted, and depended on for a decade — in a domain where the cost of an error isn't an inconvenience, it's the wrong number of dollars going to the wrong school.

That's the case for taking on hard, high-stakes domains directly rather than working around them: financial-calculation systems, formulas with legal and policy weight built in, integrations into systems of record that can't be gotten wrong. The proof that matters for work like this isn't always a number produced the week the project ends. Sometimes it's what the system is still doing correctly ten years later, and what it takes to keep it that way.