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.
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.
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.
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.
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
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.
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.
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
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.