About
I'm Nick Butlin. I started as a systems engineer in aerospace, right under the thundering waterfall, which is where I learned the V-model and the difference between verification and validation. Every level on the way up the V answers the level opposite it on the way down, and the reason the arms are joined at the bottom and open at the top is that conformance can be checked locally and correctness cannot. I have written software ever since and I have never stopped thinking in that shape.
I co-founded BetterFleet. We build software for people who run large vehicle fleets and are electrifying them - depots, chargers, vehicles, drivers, energy contracts, and the daily question of whether every vehicle will leave in the morning with enough charge to finish its route. Most of the examples here come from there.
The domain is second-hand. Entelligence was an energy intelligence company I started, one of several businesses I have started in energy tech. The company is gone. The name was better than the company, so I kept it.
There is an older one, and it is funnier. My family was in shoes. About fifteen years ago I started a company called BetterFeet - scan your feet at home, 3D-print the insoles and soles to match. I now work at BetterFleet. Shoes for wheels, and I kept the adjective.
Underneath all of it is a long interest in knowledge work and cognitive intelligence: how people think, what technology does to thinking, and where AI takes that next. I have read science fiction all my life and that is probably where it started. Science fiction is where you go to find out what a technology means before it arrives. The rest is building - using the technology to solve real problems and make products worth using.
What I argue
A part cannot be validated from inside itself. Local coherence is not evidence of global correctness. A component can pass every test it was given and still be the wrong component, because whether it should exist at all is not a question answerable from where it stands. I have shown my workings in software, because that is where I have them, but there is nothing about software in the claim.
It is one claim among several, and it did not arrive on its own. The rest of what I hold is on the Thinking pages, pulled from a notebook I have been keeping for a while, each page dated with when I last checked it.
I have been on the wrong side of it. We had a dispatch product and a customer who asked for everything, working, on the first day - every vehicle, every charger, every route, every exception, all of it agreeing with itself. I heard that as a customer who had not understood how software gets built. They were describing something true about their problem. A depot manager cannot dispatch ninety per cent of the routes, because the ten per cent the system does not cover is not ten per cent of the problem. It is all of it: they still have to check the lot to find out which ten per cent it is, which is the job they were doing before we turned up. We cut the system into parts and finished them one at a time, and then went back and filled in every rung we had skipped. We were not insufficiently agile. We shipped fast, we listened, we built what was asked for, and the method produced the wrong system.
The thing I have not resolved: the cost of holding a whole system in mind is collapsing, which I think is mostly good, and it also removes the ladder the average junior engineer used to climb. I don't know how they're going to gain those skills, if I'm brutally honest, and I am not going to pretend the two cancel out.