Dr Neil Davies does not begin with code. He begins with mathematics, with constraints, with risk, and with the uncomfortable possibility that a proposed system should never be built at all. In an industry still inclined to celebrate speed, Davies, co founder of Predictable Network Solutions, (PNSol), takes a different line. “What we’re trying to do is make sure it doesn’t fail,” he says. That distinction sits at the centre of his work and of his argument about what makes software scalable.
Dr Davies came out of the University of Bristol, where he studied computer science and then stayed on for more than two decades. His PhD focused on “the performance modelling and performance engineering of complex distributed systems”, a field he describes as important but rarely glamorous. His interest, he says, has long been in “how you make complex, interacting distributed systems perform well, cost effectively, delivering on their requirements, scaling”. It is telling that he is drawn not to the fashionable edge of computing but to the parts most likely to be ignored until they go wrong.
That thinking now informs the work of PNSol, the company he founded after leaving an earlier commercial venture built around university research. PNSol is not large, but it is specialised. Its work is what Davies calls ex ante performance engineering: reasoning about performance before a system is built. “Before you build it, you can actually reason about it,” he says. To do so, the company developed a mathematical approach known as ∆Q (Delta Q), now taught in universities.
The importance of that method lies in where it places attention. Dr Davies gives a simple example. A supermarket may look at the checkout as a resource to be managed. The customer experiences it differently. The real question is how long the queue takes, how long the wait lasts, and whether the service is tolerable. His approach is “outcome centric”, concerned less with the utilisation of resources than with the quality of the experience delivered. That may sound abstract, but it has practical consequences. It pushes design away from internal engineering preferences and towards what the system must actually do, at the required scale, for the person or institution depending on it.
Dr Davies is clear that this thinking matters most when software is not disposable. “If you build infrastructure which you’re going to rely on for decades,” he says, then longevity, safety and recoverability cannot be left until later. Yet much of the industry still works in the opposite order.
“Lots of other people make something work and then try and fix those problems later,” he says, only to discover that early design choices have already made that impossible. The result is familiar enough: systems are rebuilt, budgets are consumed, and projects are written off as though failure were merely an operational inconvenience rather than a design error.
This is where Dr Davies is most unsentimental. Some software projects, he argues, are not late or poorly run. They are infeasible from the start. “The universe doesn’t permit it to be built,” he says. That is not a rhetorical flourish. It is the consequence of asking too much of the technology, or failing to understand the scale at which it must perform, or setting requirements that contradict one another. The point of modelling early is not simply to improve efficiency. It is to establish whether the proposed system can work at all.
“You can do a lot of that without ever writing a line of code,” he says. That is not a rejection of coding. It is a reminder that the expensive part of software is often not writing it, but maintaining the wrong thing for years afterwards. Dr Davies puts it bluntly: “Running something is 10, 100 times more expensive than building it.”
His work with Cardano offers a useful example of the argument in practice. Dr Davies and his colleagues were involved in designing the protocols that let the network scale and recover from failure. The part he discusses most readily is what he calls the “data diffusion layer”, the substrate beneath the blockchain itself that passes information between nodes.
“The blockchain is just a distributed ledger,” he says. “In order to communicate what was done with the transactions and communicate the blockchains, you need this substrate underneath it.”
That layer, he says, has run continuously since launch, surviving outages and disruptions. “The system is self-organising and self-healing.”
This is important because it shifts attention from the visible product to the architecture that makes the visible product trustworthy. Dr Davies is not interested in software that works only while conditions are favourable. He is interested in systems that degrade gracefully, recover automatically and continue operating even under stress.
In Cardano’s case, he describes a system designed so that if major network links between continents were severed, it would “hardly notice” and would continue running. That is scalability in its serious form: not simply more transactions per second, but resilience under real world conditions.
That same thinking informs his work on Tachys and on partner chain models. Here Dr Davies moves from pure engineering to the governance concerns of large organisations. Public, unpermissioned systems can be robust, but many corporates struggle with the lack of clear accountability.
“They want a throat to choke,” he says, using the familiar business phrase for a party that can contractually hold residual risk. This is not merely a cultural preference. It is part of how boards understand liability, governance and legitimacy. In that context, scalability is not only technical. It is organisational. A system may be mathematically sound and still fail to win adoption if no one can own the risk in a form institutions recognise.
Dr Davies’s answer is to think in terms of trade-offs that can be modelled in advance. A global, unpermissioned chain has one set of properties. A geographically bounded, permissioned or semi permissioned chain has another. Change the schedule, narrow the geography, specify the operating conditions, and performance improves.
“All you’ve done is change the schedule. You don’t have to change any of the other code,” he says. The value of that approach is not only speed. It is predictability. “You should be able to predict the effect of the thing you should see,” he says. The discipline is straightforward: “You do the maths, you make some predictions, you try it out.”
What emerges from all this is a disciplined approach to scalable software. Define the outcomes first. Evaluate risk early. Establish whether the system is feasible before committing resources. Build recovery, security and maintainability into the architecture from day one. Understand the governance model of the customer, not just the elegance of the technology.
Dr Davies puts it well when he says, “I never sell to my customer. I sell to my customer’s customer.” In other words, software succeeds when it solves the deeper operational problem, not when it merely satisfies the immediate commissioning brief.
He is equally clear that the rise of AI does not diminish that requirement. AI may generate code quickly, but “it can’t do things like verification and validation. It can’t tell you what you intended.” Code, in that view, is becoming cheaper. Thought is not. The durable value lies in specification, modelling, validation and architecture. “The value doesn’t lie in the software. The value lies in the processes it enables,” he says.
For Davies, then, scalability is not a late-stage optimisation. It is an early act of judgement. “We didn’t build a blockchain. We built a sustainable blockchain,” he says. That sentence probably serves as well as any mission statement for the work of PNSol. The message is simple enough. Build methodically. Evaluate risk before enthusiasm takes over. Decide what must endure. Then, and only then, write the code.
