KISS. Keep it simple. That’s hardly a message to be argued with, is it?
Complexity is the enemy of flexibility. It ties us up in unintended consequences, blocking our attempts to change. It hides defects. It makes it impossible to assure that our systems will function correctly. Security. Performance. Transparency. All of these highly desirable attributes leak away in the face of increasing complexity.
Yet ever increasing complexity is one of the underlying tenets of the IT industry. Moore’s Law is often stated in terms of increasing transistor counts, but it was originally about complexity: “The complexity for minimum component costs has increased at a rate of roughly a factor of two per year…”. Increased complexity in the underlying hardware pushes complexity up the stack – more complex operating systems to control the hardware; more complex compilers to build applications on top of the operating systems; more complex databases. And so on. If Moore’s Law drives the industry, then no wonder we’re enmeshed in complexity.
Now, it seems, this complexity has caught up with us. Reports by consultancies such as PwC (“Why isn’t IT spending creating more value?”) conclude that the growing complexity of our IT systems is limiting return on investment in IT. While such investment led to impressive productivity gains in the 1990’s, by the early 2000’s any gain was being cancelled out by the costs of complexity – higher development and maintenance and security costs, for example.
In the face of this trend, it’s easy to fall back to that opening message: keep it simple. It’s easy to look at the IT industry and see a fatal attraction to complexity. Engineers are bright people. They can tolerate a lot of complexity. They gain power by building systems that flaunt this complexity. If only we could persuade them to focus their intellect on eliminating complexity. Can’t we find a way to push them towards simple elegance?
The problem with this message is that we almost never eliminate complexity. When we do create a system that appears simple, we often do it by shifting the complexity somewhere else in the technology stack. The iPhone has a simple user interface because someone’s done a lot of complex user research and spent a lot of time developing complex user interface code. We start playing with our Wii’s as soon as we pick them up because large teams spent a lot of time developing complex hardware and software. Many such systems actually increase overall complexity dramatically: in order to gain simplicity in one dimension, they build lots of additional complexity elsewhere.
Cloud computing provides another good example. Running an application on a virtualised cloud of servers is much more complex than running it on specific, physical servers in a specific, physical datacentre. For a start, we need to add another complex piece of software – the hypervisor – to the stack. That software needs to be tested. It needs to be managed. We also add complexity to message routing algorithms, to authentication protocols, and so on. Cloud computing doesn’t add value because it’s simpler than client-server or mainframe computing. It adds value because it shifts the additional complexity to a place where it can be managed more effectively. Amazon and Google and companies of their ilk are simply a lot better at managing servers and operating systems than most other organisations could ever hope to be. When it lets Google manage this complexity, an enterprise can focus more of its own resources on innovation and growth within its core business.
We shift complexity in other ways too. Paying attention to governance, for example. It’s hard work, but good governance helps us shift complex politics away from operational decision making. This then allows customer-facing teams to focus their energy on understanding the customer and meeting their needs.
Or consider outsourcing. Outsourcing generally succeeds by shifting complexity to a service provider who has the skills to manage it effectively. Conversely, outsourcing tends to fail when it shifts complexity into the legal instruments around the deal. No-one can manage legal complexity cheaply.
And that brings us back to my wariness of the easy message – keep it simple. People who try to fake simplicity generally end up shifting their complexity to some hidden place, where no-one can manage it. It’s much more effective to bring the complexity out into the open, where it can be dealt with. To do this, we need to recognise the complexity, not rail against it.
So if we want to continue to gain benefits from IT, we need to avoid the siren’s song to reduce complexity. Complexity exists. Good solutions acknowledge that complexity. They shift it to places where it can be managed effectively. They respect the words of Albert Einstein: “Make everything as simple as possible. But no simpler.”
Graham Oakes helps people untangle complex technology, relationships, processes and governance. His book Project Reviews, Assurance and Governance is about finding and managing the complexity in our projects and programmes. It was published by Gower Publishing in October, 2008.