Building Things Because They Should Exist

A surprisingly large percentage of the things I build begin with the same sentence: “Why the hell doesn’t this exist?” This is not always a financially responsible question. It is, however, an excellent engineering question. I don’t tend to begin with technology. I begin with friction. Somebody is doing something manually that a computer should be doing. Two systems contain information the other desperately needs but can’t exchange.

A perfectly good piece of hardware has one absurd limitation. A workflow requires six people to babysit it because nobody designed the whole process. Or I have a 1999 karaoke machine and decide it needs computer vision. That last category is admittedly harder to defend in a board meeting. But the thought process is basically the same. I think engineers sometimes become overly attached to technologies.

What’s the AI strategy? What’s the cloud strategy? Should this run on Kubernetes? Can we put a blockchain in it? Please don’t. The technology is downstream from the problem. Start with the thing that should happen. Then work backward. Séance Bot is a silly example with a serious architecture behind it. The desired outcome isn’t “run OpenCV on a Raspberry Pi.” Nobody interacting with it cares.

The desired outcome is that the face inside the machine appears to notice you. Computer vision happens to be useful for accomplishing that. Likewise, Scan Bridge came from a boundary problem. There are environments full of multifunction printers and scanners that work perfectly well but were never designed around a modern, integrated document workflow. Throwing away functional hardware because it doesn’t speak the exact protocol or workflow you want is one solution.

Building a bridge is another. Coverity came from a similar observation at a much larger scale. A signing isn’t conceptually complicated. Documents need to reach the correct qualified person. That person needs to reach the signer. The appointment needs to happen. The results need to return. Everybody needs to know what state the transaction is in. Yet the boundaries between companies, people, documents and software turn that simple description into a surprisingly complicated operational problem.

Again: Why doesn’t this just work? That’s the question I enjoy. And “because the systems are different” has never been a particularly satisfying answer to me. Of course they’re different. That’s why integration engineering exists. The most interesting systems I’ve built have lived at boundaries. Hardware and software. Old and new. Human and automated. Physical and digital. One company and another. Those boundaries are where assumptions stop matching.

They’re also where useful products tend to appear. There’s another advantage to building this way. You become relatively immune to technology fashion. I’ve been working in technology long enough to watch several things become the future, stop being the future, become legacy, and then become the future again under a different name. The underlying problems are much more stable. Move information reliably. Establish identity. Coordinate work.

Reduce ambiguity. Give people the information they need when they need it. Respond to the physical world. Make systems recover when things go wrong. Those problems survive every Gartner diagram ever produced. So when I build something, I tend to ask three questions. What should happen? Why doesn’t it happen now? What is the smallest system I can build that changes that? Sometimes the answer becomes a company.

Sometimes it becomes infrastructure. Sometimes it becomes a little Raspberry Pi appliance. And sometimes it becomes a haunted karaoke machine with a crystal ball. Engineering contains multitudes.