Who are you optimising for?

A long time ago, one of my colleagues gave me a reality check. I was working as an architect and he was working as a methods specialist. I thought that our jobs were important, but he reminded me what was really important when he said, ‘We’re here to deliver working software. If we’re not doing that directly, we have to ask whether we’re doing our best for the people who do deliver working software.’

A few months ago, I wrote an article which asked the question, ‘what are you optimising for?’ when attempting Cloud transformation. Today I’d like to ask a question which I think is even more important: ‘who are you optimising for?’

Running technology involves compromise, and you can’t optimise for everybody. You usually have less time, money or resources than you would like, and you have to make choices. You have to make optimisation choices based on your most pressing needs and your tightest constraints. And the economic and operational characteristics of on-premise infrastructure mean that it has often not been optimised for the people who deliver working software: for developers (and also for data scientists - but the difference between these two groups of value producing people is a subject of a future blog.)

Infrastructure operations teams within large, traditional enterprises are often stretched, and get more stretched every year. They have to manage a heterogeneous estate which has grown over many years, to which new technologies are added all the time. Expectations of reliability increase as surely as budgets decrease, and so do cyber threats and the pressure on currency. It should be no surprise that infrastructure operations teams therefore typically optimise for infrastructure operations, adopting tools and processes which enable them to manage a large, complex, ageing estate with limited resources.

But, as an example of the tension which led to the development of DevOps as a discipline, optimising for infrastructure operations in a traditional technology estate typically means setting a lower priority for the developer experience. It is common to hear development teams complaining about the time taken to commission environments and about lengthy approval processes intended to protect production. (There’s another version of this story in this article.)

I believe that Cloud transformation enables us to change this story. As I’ve written before, Cloud platforms are not just places to run code and store data: they are fully architected, comprehensively instrumented platforms which, used well, allow us to achieve levels of reliability, resilience, security and flexibility which we could not achieve before.

Of course, with improved experience comes enhanced accountability. Optimising for developer experience on Cloud does not mean letting every developer use every piece of technology they want. Cloud platforms are platforms, and part of their value comes from an opinionated and standard of technologies managed through APIs: creativity should be applied at the software layer. And shifting to a DevOps model on Cloud means accepting responsibility for operations as well as development - but I have a suspicion that this is what developers have always wanted anyway.

Most people, when adopting Cloud platforms, try to avoid bringing practices from their on-premise environments which are no longer needed on Cloud. However, this is not easy, and it can be hard to know which practices to retain and which to abandon. I believe that we can help ourselves by adopting that advice from my colleague, and asking ourselves whether we are doing the best for the people who deliver working software: are we optimising for developers? And we shouldn’t just ask this question because it’s fashionable to champion developers: we should ask it because working software is what makes a difference to customers and end users.

(Views in this article are my own.)