Accidentally Agile: What Your Finance Team's Cursed Spreadsheets Can Teach Your Engineers

There's a spreadsheet living somewhere in a British company right now — possibly yours — that has no right to work as well as it does. It's colour-coded with a logic system only one person fully understands. It has seventeen tabs, a VBA macro that runs every Monday morning without fail, and a comment in cell Q47 that simply reads: 'DO NOT TOUCH THIS.' It has been running reliably since the second Cameron government. Nobody is entirely sure how.

And yet, it works. Every single time.

Meanwhile, the engineering team's microservices architecture — lovingly crafted, properly documented, and deployed via a CI/CD pipeline that cost four months to configure — fell over last Tuesday because someone bumped a dependency version.

Something has gone quietly, magnificently wrong.

The Accidental Programmers in the Corner Office

Let's be honest about what Excel and Google Sheets actually are. They are programming environments. Not glamorous ones, certainly — nobody's putting 'VLOOKUP practitioner' on their conference lanyard — but functional, logical systems that require genuine abstract thinking to use well. A well-constructed spreadsheet model involves conditional logic, data normalisation, error handling, and iterative testing. Sound familiar?

The difference is that finance and ops teams didn't get the memo that building software was supposed to be complicated. They just needed to solve a problem before the board meeting on Thursday, so they got on with it.

This is the secret weapon of the accidental coder: ruthless constraint. There's no sprint planning. There's no architecture review board. There's a deadline, a business problem, and a copy of Excel. The result, counterintuitively, is often something extraordinarily fit for purpose.

British accountants and operations managers have been quietly practising a kind of extreme pragmatism that most engineering teams only claim to aspire to. They build for the user they know — themselves — and they iterate constantly, because their lives depend on the thing actually working.

Why Constraint Breeds Reliability

Here's a thought experiment. Ask a senior developer to build you a system to track invoice reconciliation. You'll get a requirements document, a technology proposal, and possibly a lengthy discussion about whether this warrants its own microservice. Arrive back in six weeks.

Ask the finance manager to do the same thing and she'll have a working prototype by Friday afternoon. It won't be pretty. It will probably contain at least one formula that makes a proper developer's eye twitch. But it will reconcile invoices, it will flag anomalies, and it will send a summary to the right people at the right time.

The reason isn't that she's more talented than the developer — though she might well be. It's that she's operating under constraints that force good decisions. She can't over-engineer it, because she doesn't have the tools. She can't abstract it into oblivion, because she needs to use it tomorrow. She can't ignore the edge cases, because she is the edge case.

Constraint, it turns out, is one of the most underrated features a development environment can have.

The Hidden Quality Metrics Nobody's Measuring

Software engineering teams have elaborate quality metrics: code coverage, cyclomatic complexity, mean time to recovery. Finance teams have one metric: does it give the right answer?

This sounds reductive, but it's worth sitting with for a moment. Because 'does it give the right answer' is, ultimately, the only metric that matters to an end user. The rest are proxies — useful, important proxies, but proxies nonetheless.

The spreadsheet whisperers of Britain's finance departments have been doing end-to-end testing since before most developers knew what the phrase meant. They check their outputs against known values. They build in sanity checks. They get a colleague to try to break it before they trust it. They are, in other words, doing quality assurance — they've just never called it that.

What Engineers Can Actually Learn Here

None of this is to suggest that VBA is a superior paradigm to proper software engineering. It absolutely isn't. Spreadsheets don't scale, they're nightmares to version control, and the day Janet leaves the company is the day the whole thing becomes archaeology.

But the approach — the discipline, the pragmatism, the relentless focus on solving the actual problem rather than the theoretical elegant version of the problem — is worth stealing wholesale.

A few things engineering teams might genuinely consider:

Start with the constraint, not the capability. Before you reach for a new tool or framework, ask what you'd build if you only had the tools you already have. The answer is often simpler, faster, and more maintainable than whatever you were about to propose.

Build for yourself first. The finance team's spreadsheets work because they're built by the person who uses them. The closer developers can get to that tight feedback loop — actually using the things they build — the better those things tend to get.

Respect the boring solution. A macro that runs every Monday morning and hasn't broken in a decade is a remarkable piece of engineering. The fact that it's not written in Rust doesn't make it less so.

Test against reality, not theory. The finance manager checks her reconciliation output against the bank statement. She doesn't check whether her code has 80% test coverage. Both matter, but one of them matters more.

The Mutual Respect Problem

There's a cultural issue here that's worth naming directly. Engineering teams, particularly in British tech companies, have a long and slightly embarrassing tradition of dismissing spreadsheet-based solutions as unsophisticated. 'We should really build something proper for this,' someone will say, approximately eighteen months before the 'proper' solution is delivered, over budget, and somehow less reliable than the thing it replaced.

Finance teams, meanwhile, have learned not to ask engineering for help, because the last time they did it took six months and the result didn't do what they needed. So they built it themselves. And it worked. And they quietly got on with their jobs.

Both sides are losing from this standoff. Engineers miss out on genuine insight into how real users solve real problems under real constraints. Finance teams end up maintaining systems that are genuinely fragile and undocumented, because nobody with the skills to make them robust ever took them seriously enough to help.

A Modest Proposal

The next time someone in your ops or finance team shows you a spreadsheet they've built, resist the urge to immediately suggest rewriting it. Instead, ask them to walk you through how it works. Ask what it needs to handle. Ask what happens when it goes wrong and how they know.

You might be surprised by how much rigour you find hiding under the conditional formatting.

Britain's accidental coders have been solving real problems with genuine elegance for decades. The least we can do is pay attention.

And maybe, just maybe, leave cell Q47 alone.