Why I Left the FBI to Start a Software Company I love this story. Basically some programmers packed it in to join the FBI. They worked as operational special agents for several years, until their frustrations with agency IT forced them to just build their own tools guerrilla-style, so they could fight crime better.

What drove us was our rejection of the status quo for law enforcement and security solutions, as well as the painstakingly slow pace of the government bureaucracy. Every single day, we followed the mantra of “build high quality software faster than people can say no.”

Their solution eventually replaced a failed top-down $450m outsourced megaproject. They left the FBI to sell their case management software full time. The whole company is basically former operational law enforcement. When they realised they couldn't pull the same trick for beat cops as they did for federal investigators, what did they do? Extensive research around these new user needs?? No, one of the founders got a job as a traffic cop.

Before we turned the Sentinel project around, I saw first-hand how user needs were consistently not met by the software engineers. It wasn’t because the engineers didn’t want to meet their needs. On the contrary, non-technical users frequently had trouble communicating their needs to the engineers. Likewise, the engineers frequently misunderstood how the users actually did their jobs, and made inaccurate assumptions about what would and would not work for the end users. One of the keys to our success with the Sentinel project was our unique dual roles as both end users and software engineers. There was nothing “lost in translation” between the end users and the engineers, since they were one and the same. Not wanting to repeat the same mistakes, there was only one thing to do — one of us needed to become a local law enforcement officer.

One of my long-time claims is that one the main reasons for all the problems we complain about in computing is software developers considering themselves as possessing an abstract universal competence about software. Much like managers believe that they can manage anything that looks manageable. The application domain is not important, and domain experts are clients, not collaborators. That's mostly an attitude problem, not a competence problem. And the attitude can only survive because the victims tend to share the same belief.

Yes, the job of the programmer, manager, consultant, is basically to systemise something that might actually be beyond human ability to systemise, but they back themselves to do it. They are insulated from the consequences in a way practitioners aren't. This blog has some great articles around this https://desystemize.substack.com/

@Chris Knott The Desystemize site reminds me a lot of James Scott's "Seeing like a state". Which I think points to the priblem is systemizing. It's not the fact that we do it, because we have to, but that there are few big systems rather then many small ones. It's "the state", "the tech industry", etc. The implicit idea of universality. It was a big idea of the last century ("universal human rights" "universal truth through science", ...) but I think it's time is over.