There's a growing recognition of a fundamental disconnect throughout Britain's tech sector. We've created development processes that demand perfect logical thinking, whilst stubbornly ignoring the wonderfully imperfect human minds that implement them.
The contradiction is striking when you think about it. We acknowledge that humans make irrational decisions in nearly every aspect of life—from panic-buying petrol and toilet roll during shortages to making impulse purchases at the supermarket till—yet somehow expect software engineers to operate with computer-like precision and consistency.
The Rational Fantasy
Behavioural economics has taught us something profound about human nature: we're not the rational actors that traditional economic models presume us to be. Why then do we expect software developers to behave like perfectly organised machines?
The waterfall methodology emerged as software's equivalent of rigid central planning—everything mapped out in meticulous detail from start to finish. Perfect on paper, absolute chaos in practice.
It's taken decades of missed deadlines and budget overruns to acknowledge that rigid, linear approaches simply don't align with how humans naturally work. The penny finally dropped in the early 2000s with the emergence of agile methodologies.
People Over Process
The first principle of the Agile Manifesto reads like a revelation: "Individuals and interactions over processes and tools." It's a strikingly humane perspective – recognise that your team consists of actual human beings, not code-producing automatons.
In countless planning sessions across the UK, teams struggle with the abstract nature of story points. Half the room might interpret a '3' entirely differently from a '5', making the exercise somewhat like trying to measure distance in unicorns.
When processes fail to align with natural human behaviour, they're destined for the same fate as New Year's resolutions to join the gym – abandoned by February.
The Estimation Conundrum
Time estimation represents another fascinating collision between theory and reality. We've all been there – confidently declaring a task will take a day, only to find ourselves still tinkering with it a week later.
Across many UK development teams, the abstract nature of story points has proven problematic. Some forward-thinking project managers have switched to time estimates – not because they're necessarily more accurate, but because humans naturally think in terms of time. We've been processing the concept of time since childhood, making it a more intuitive framework for estimation despite its imperfections.
Many teams find they complete roughly 60 hours of estimated work in a 200-hour sprint. But the ratio isn't the point. What matters is having a shared understanding of capacity, even if that understanding acknowledges a collective inability to estimate accurately.
The Testing Paradox
Perhaps nowhere is the gap between intention and behaviour more evident than in test-driven development. At conferences across the UK, developers nod enthusiastically when speakers extol the virtues of comprehensive testing. Yet back at their desks, many of these same individuals will cheerfully commit untested code.
The prevailing wisdom suggests that developers will test more if we make testing easier. But that's rather like assuming that making vegetables more accessible will suddenly turn Britain into a nation of vegetarians.
The real issue isn't friction. Writing application code gives developers a dopamine hit—they've created something tangible that works. Writing tests simply doesn't provide the same psychological reward, regardless of how much we intellectually understand their value.
Rethinking Code Reviews
The standard approach to code reviews – write all the code, then have someone review it – seems sensible enough. It's also a recipe for awkwardness on par with a bad episode of The Office.
Imagine spending days crafting what you believe is elegant code, only to be told it requires a complete rewrite. Few developers have the emotional detachment to accept such feedback gracefully, and few reviewers have the fortitude to insist upon it. The result? Suboptimal code slips through with vague promises of future refactoring.
Progressive code reviews represent a more human-friendly approach. It's like the difference between having your PhD thesis reviewed all at once versus chapter by chapter. The latter allows for course correction before you've gone too far astray.
The Management Fallacy
For many managers, there's a temptation to adopt practices wholesale from successful firms. If it works for the Silicon Roundabout unicorns, surely it will work for us?
This cookbook approach to management misses a crucial ingredient: your specific team with its unique blend of personalities, strengths, and quirks. Although theoretically useful, one-size-fits-all approaches to software development are unlikely to be right for every situation.
A More Human Approach
The future of effective software development may not lie in more rigid methodologies or clever technical solutions, but in a deeper understanding of human psychology and behaviour.
The most successful tech leaders are those who design their processes around how developers naturally work, rather than how they wish developers would work. They acknowledge human limitations, quirks, and motivations, building systems that harness these realities rather than fighting against them. Perhaps the most valuable skill won't be coding expertise or technical knowledge but the ability to understand and work with the beautifully imperfect humans who build our digital products.
After all, as any good project manager knows, sometimes the most productive thing you can do is stop trying to optimise the process and simply put the kettle on instead.