What if we behaved as if we cared about technology?

There is a puzzle in enterprise technology.

We spend a lot of time building systems and making them work. We make business cases, we gain sponsorship, we plan investments, we organise programmes and projects, and, eventually, sometimes after a large amount of mayhem and drama, we get something into production.

And then, after all that work in building systems, we spend a lot of time and effort getting rid of them. We count up our number of applications, and feel bad if the number is higher than it was last year. We put systems on the list of things to be decommissioned, and feel bad if we fail to decommission them. We call systems ‘legacy’ and ‘heritage’ and other euphemisms for ‘old’ - and recognise that all of these labels denote something that we would rather not have.

To someone who knew nothing about enterprise technology, our behaviour would seem very strange. It would be as if, in the physical world, we spent time and effort building a bridge, and, as soon as it was in place, started lamenting the cost of maintaining it, regretting the type of steel and the colour of the paint, and started planning how to tear it down again.

Why do we behave this way? Do we really believe that less technology is better than more technology? If so, why do we build it at all? Or do we believe that more technology is better than less technology? If so, why don’t we make the case for having more of it?

As I have written before, I think that there is a huge divide in understanding between people who have had the chance to work with technology throughout their careers and those who have not. I also think that those of us who work with enterprise technology have a duty to explain, and that we have largely been unsuccessful in fulfilling that duty. As a result, much of the narrative about enterprise technology is driven by this lack of understanding, and our failure to explain.

Business leaders quite rightly want to control costs; they correlate the cost of technology with the number of bits of technology they have, and reasonably assume that fewer bits of technology means lower cost. Business leaders quite rightly want certainty of return on their investments; they have been presented with business cases for projects that deliver that return, and reasonably assume that projects are a good way to build software. Business leaders want projects to go faster; they are told that technology complexity inhibits speed, and reasonably assume that cutting complexity by reducing the amount of technology is a good thing.

I believe that all of these reactions are reasonable but wrong,?and that we should take the time to explain why.

I believe that we should take the time to explain why more technology is better than less technology: that technology has transformed the way we run our business and live our lives, and that the world would be a very different place if it didn’t exist.

I believe that we should take the time to explain that, while bad technology is bad, good technology is good, and that good technology is technology that is cared for. Many of the ways in which we operate in large enterprises seem optimised to deliver technology that is not cared for: we cut the time we need for testing, and cut the time we need to build automated tests even more; we organise our work into projects, and don’t pay enough attention to the product when the project is finished; we defer maintenance and upgrades until the last possible moment, and then do them in a rush.

I believe that we should take the time to explain that complexity is not bad. Many of the most important capabilities that humanity has ever built, such as the Internet, are incredibly complex, yet they still work, and they still create enormous value. If complex systems are built on a foundation of simple protocols, then they are not only valuable, they may also be surprisingly resilient and efficient.

However, I also believe that we need to do more than just take the time to explain: I think that we need to change the way we express our attitudes towards technology. I started working with technology long before anyone paid me to do it: I was part of that generation of bedroom programmers who grew up with micro-computers. I was delighted to get my first paying programming job because I really enjoyed programming, and thought it was possible to do cool and interesting things with code. I can remember the thrill of getting my first mainframe logon, and thinking of how much power I now had at my disposal. I can hear the sound of my first dial up modem, and remember my excitement at the idea of being connected to a worldwide network. I can remember my first system going into production, and the satisfaction of seeing it used by real, live humans. And so on and so on, up to the excitement today of seeing a code deployment pipeline execute successfully, or seeing an app come to life on someone’s phone, or seeing a machine learning model get more and more effective.

Technology is exciting and powerful. When we do it well, it transforms the companies we work for and the lives of their customers. We should be enthusiastic and evangelical. We should explain technology with patience, but we should also explain it with passion. We should make the case of building more stuff that matters, and building it well. The puzzle in enterprise technology is not why we build it up, only to tear it down, but why we struggle to make the case for using the astonishing products of human creativity to their full potential. And one solution to that puzzle is to behave as if technology is something worth caring about.

(Views in this article are my own.)