DevOps Culture Challenges

In my current role, I face a number of non-technical challenges, it can be an incredibly long winded & sometimes interesting (other times not so interesting) process. This can include with reducing blockers to allow developers to implement newer technologies, this could also include destroying silos in the work place, etc.

In my little experience, I’ve found that in order to get the most out of DevOps, you really need to embrace the cultural changes that come with this manner of working. One example of how I’m trying to encourage my team to embrace a more DevOps culture is by embracing better communication practices. Rather than communicating with colleagues that you may chat with on a daily basis, I fail to see the harm in discussing problems across a wider array of people. In my eyes, the more input & the wider the variety of input, the better, people will have different ideas & different experiences, so surely that’ll only improve the overall quality of a given product.

An example of one way that I have personally enforced my colleagues to embrace such changes is just by simply creating chats via MS Teams, where I bring people from an array of different groups together. Ranging from developers of different stacks, to system/environment engineers, to managers, to architects & so on. I found that having such discussions with such a wide variety of people can really help everyone get on the same page with regards to the knowledge. In doing so I’ve found that I’ve been able to slowly break down these silos of knowledge, encouraging people of different teams to collaborate with each other. Discussing all kinda topics from some cloud infrastructure architectures all the way through to what unit test frameworks that we’d use & so on.

My biggest beef with silos in the work place is that it can minimise productivity, not knowing who to go to about a certain topic isn’t exactly an effective way to work. The worst part, due to the fact that I’ve only been in my role for such a short time, there’s still loads of people that I’ve not spoken with, though I intend to change that in the near future.

One thing that I hate working in a bank is when people try to shut down my attempts to increase productivity, often phrases such as “we’re a bank, not a tech start-up” get thrown around. I appreciate that working in finance you need to minimise the risk & cost, but that doesn’t mean that you can’t use technologies that are mature but still somewhat new & relevant, such as Docker. I honestly can’t emphasise enough how much I hate that answer, in my humble opinion, I think that’s just some peoples way of saying “long story short, I can’t be arsed to deal with this…”. Even when looking at things strictly from a risk perspective, if you were to incorporate a proper DevOps mentality, you’d have even more quality checks to minimise risk, increasing an audit trail, etc. I mean that’s one large purpose behind quality assurance, you essentially seek to do two things; increase the quality of a given product & decrease the risk associated with a given product. A good example I like is how you could use several security scanning tools, from application layer scanners such as Synk to something like Twistlock & so on. By having such tooling in place, you’re using modern technologies for modern problems, but you’re also ensuring that you’re not a using a “bull at the gate” mentality, you’re taking the necessary steps to ensure that there’s as little risk associated with such practices.

Even when people use the argument that it’ll take time for engineers to apply the necessary engineering effort(s) to updating & upgrading technologies, realistically that’s not a valid argument in my eyes. As long as engineering teams can crack on with maintaining legacy solutions, I fail to see why they can’t also set some time aside to work on upgrading these legacy solutions. Sure it won’t be an over night process, but in the long run by reducing complexity & any unnecessary nonsense you’re ultimately setting your project(s) up for success rather than failure by sticking to what you know.

When it comes to technologies, I always try to encourage engineers to utilise platform agnostic solutions, whether that’s containers since you can use containers on Mac, Windows or Linux. Or even if it’s picking a programming language, it is honestly a part of the reason why I love working with both Java & JavaScript, they can run on pretty much anything. Though, my personal preference is to work with JavaScript, mostly because I find that a lot of the documentation & standards are more modern, I mean when looking at JEE documentation, it’s possible you may encounter some documentation that’s nearly as old as me. That’s not a problem with the Java language itself, I still love Java, i.e. I freaking love implementing clean & reliable web services with Spring Boot. Anyway I’m getting a little off topic now…

Conclusion

If you’re looking to implement DevOps, do it right, ensure that you’re following best practices, whether that’s enforcing hard & fast unit test coverage metrics, i.e. 90%+. Or whether it includes using technologies such as ESLint to enforce a consistent coding style, etc. The more ways in which you enforce quality the better, if an application that’s in development isn’t up to par with the minimal quality standards then it simply can’t make it’s way into any environment. In my opinion when a developer goes to build this application, again, if it’s not up to par, then it should simply fail to build, end of. This ensures that you can’t even deploy an application with little quality to any environment, even if it is just a development environment, it enforces quality & excellence at every stage of the development life-cycle. If that isn’t one core aspect of DevOps, then I’m clearly doing something wrong & I’m talking a load of nonsense! 😂