Getting to the Truth

One of the most enjoyable things about building software is that it requires the developers to dig around in other domains. If you’re writing financial software, you need to know how the industry works, understand the terminology, and all of the complex details underneath. If you build something for the printing industry, you need to grok their equipment and business models. Everything you write depends on knowledge from elsewhere.

For a naturally curious person like myself, this is a huge benefit. Basically a license to try and learn as much about the world as I can.

Every domain I’ve ever worked in has had a fascinating array of history and depth. You can’t actually solve any of their problems with software until you really understand them; until you get down to what makes them tick. Get to the roots. Get to the truth.

Software is very rigid and to automate any processes they need to be fully understood. To collect valid data you need to understand its structure, quality and volume. To make the interfaces usable you need to understand the environmental issues and the people. If you don’t get to the truth, the software either won’t work or it will cause more problems than it fixes. If your goal is to actually solve something, the only place you can do that is in reality.

But getting to the truth is a funny business. There are all sorts of people out there that will stand in your way. Sometimes it’s because they have something to hide, sometimes it because they don’t want to think about it. Sometimes they just don’t care or figure it isn’t necessary. The causes very.

Lately I’ve come to think of these people obstructing the work as ‘confused’. They are confused about what’s happening below, or above, or why you’re trying to find out, or even what value the software will bring to their lives. The reasons don’t matter, they are just confused.

Building a system on confusion isn’t any better than building an apartment building on a foundation make of foam. It’s obvious that it’s not going to work, even if it looks promising for a moment. If you build on fantasies or delusions or ignore hidden secrets, the result may run, but it’ll quickly drift away from being useful. It doesn’t matter how much data you collect if the data is scrambled or incorrect. And if you ignore the people who ultimately use the work, then they won’t use it or they’ll use it badly, causing massive support headaches. A forced, but miserable user-base can disruptive.

Software has the power to transform, but only if the embedded intelligence within it is correct, and that only occurs if the programmers were exposed to the truth. No truth, then there is no intelligence, and so the results are just burning through wasted resources. This is the fundamental rule that binds the code to something useful in the real world. We’ve known this for a long time, referring to issues like ‘ivory towers’ when talking about programmers who write systems far away from their users.

But this can also happen when the business or management players seek to block access to the truth. And it can also come about as a failure to properly complete reasonable ‘business analysis’, or because the domain experts are confused or lack enough experience. There are a multitude of different ways that confusion can enter into the process and obscure the truth. Distort reality. And without enough truth there is no understanding, which always prevents success.