Devops

My current client has an enterprise CI/CD pipeline that is maintained by a centralized team that does not use it. Its product owner(s) do not rely on its output for their revenue. They are not measured on its performance or reliability.

And yet we are obligated to use this pipeline. There’s no other option. We were also handed a microservices architecture from the Architecture team so our application is comprised of about 20 separate services, each with their own deployment pipeline, thereby magifying our sensitivity to the whims of the enterprise CI/CD pipeline.

I wrote about DRY configs many years ago but astonishingly my clients don’t seem to read my blog. I mean, who even has a blog these days anyway?

Externalized application configs have a way of multiplying like rabbits to the point where people become afraid to touch them at all, let alone apply the DRY principle to them. The proliferation of poorly-designed configuration files in Enterprise Java systems is appalling, and the situation is compounded when an external configuration system like Consul or Spring Cloud Config is added to the mix.

Me: Why is this report different to the one in production? SysAdmin: Dunno. I guess they must have fixed it production and forgot to check it back into source control.

If I had a dollar for every time I’ve had that conversation I’d be a rich man. It is usually the result of some late-night troubleshooting and finally the system is working as expected and everyone goes to bed. But the next day, nobody remembers what exactly they changed that fixed the problem, nor do they spend the time to figure it out and get it back into source control. Worse yet, they were making untested changes in a live environment - that shouldn’t be possible!.

There’s nothing that beats the feeling of being part of an exceptional team and yet it is strangely difficult to define exactly what makes one team great and another team not-so-great. Google recently set out to learn how to build the perfect team and came up with some interesting, albeit previously discovered, answers.

To summarize their findings, Google’s Project Aristotle concluded that on good teams:

1. All team members spoke roughly the same amount, and
2. Team members were empathetic towards each other

Harvard Business School’s professor Amy Edmondson described this as “a sense of confidence that the team will not embarrass, reject or punish someone for speaking up”. This may seem obvious until you find yourself on a team that crucifies anyone for speaking their mind. I have experienced those teams first hand, and believe me, they’re no fun. Conversations become antagonistic and argumentative and the team dynamic rapidly degrades.

I’ve been pushing large enterprises to adopt agile development practices for years so I was very excited when I began seeing many of them embarking upon ambitious Agile Transformation projects where they attempt to not only change the way they build software, but completely revolutionise the entire IT process from inception, finance, HR, delivery and operations.

But they rarely discuss culture.

“Culture” in this context is used to broadly describe how people behave in the company.