I was reading this article while waiting for some code to deploy this morning, and a couple of sentences really leapt out at me…
The same has been true in the IT world, or at least my IT world, for the longest time. Getting code from my machine into production is never a consistent process. It depends where I’m working, what regulatory framework is in place, what technology is being used, how advanced the organisation is.
In my current job we use a lot of the latest and greatest technologies: node.js, microservices, Docker, Kubernetes, Splunk and so on. And the philosophy we try and adopt is called “build, run, own”. That is, you take ownership over every element of the code you write, from conception through to support.
It’s a good theory, but every so often we get stuck. I do own my code, but someone else owns the Kubernetes platform, a different team is responsible for splunk and they don’t all necessarily do the right thing, especially in test environments. In some environments I’d have the ability work around these sorts of problems – muddling through – but it is not possible in this highly connected architecture where various elements present themselves as black boxes.
It makes for some interesting challenges and dependencies and means that muddling through is no longer an option. The positive is, or at least should be, that, because we have to do everything within well known, tightly defined constraints, that when my code finally reaches production it is far more stable.