Unless you’ve been working off-grid for the past few years, you won’t have been able to avoid a conversation about DevOps (development and operations) – the tech industry’s portmanteau word of the moment.
SEE ALSO, WHAT IS DEVOPS?
There was a time when each technical discipline worked in isolation – cells of expertise (developers, system administrators, testers and so on) who completed the work they were tasked to do with little or no conversation outside of their sphere. Of course this led to a number of issues, inevitably delaying projects and resulting in software which often didn’t work.
Designed to be a new way for software development functions and other IT professionals to collaborate, DevOps first came to light as a more efficient way to work back in 2008 along with agile infrastructures and other ways to improve flow through the whole of the delivery pipeline.
But is it just a marriage of convenience – a relationship which brings short-term benefits to each party but no long-lasting commitment - or something more stable and secure?
As with all relationships, there are pros and cons:
Collaboration between all technical professionals goes some considerable way to alleviate entrenched problems - the widespread acceptance that projects will always run late, won’t work properly from the start and will cost more/deliver less than anticipated. For example, developers may come up with a software solution which, on the face of it, meets all of the project’s challenges, only for the security administrator to point out that it exposes the system to unacceptable risk. Without DevOps, this would mean going back to square one. With DevOps, it’s handled, worked through and new solutions are suggested early on, saving time and money.
Issues are dealt with by team members who can take ownership and solve the problem. Working in isolation runs the risk of bugs appearing once the project goes live, and it’s often the maintenance or support teams who have to handle them. It’s likely that they would have to pass the issue up the development chain until it reaches someone who can actually provide a solution. Then it would have to pass back down the chain to the end user – an inefficient and impractical way to work.
‘Let those who create the pain, feel the pain’ - this isn’t just a negative reinforcement technique. If developers have to deal with their systems’ real world problems, it helps not just to resolve them quickly but improve them naturally over time, making decisions that are best for the user based on their experience of handling issues and requests rather than what they think a user wants.
Once you buy into the concept of DevOps, there’s a temptation to take it one step further and abandon the idea of specialists altogether. Encouraging developers to be ‘full-stack’ and multitask as QAs, system administrators and release managers etc. may seem attractive from a cost and resource point of view, and arguably most developers should be able to assume these roles. But there’s a risk that those who entered the profession because of their skill in and focus on developing software may become a ‘jack of all trades and masters of none’.
‘Working together’ doesn’t mean ‘we’re all in this together’, and on occasion the move towards DevOps has been accused of being elitist, with those on the management side of the divide setting the rules and running the show for those on the development side. Mutual respect for each other’s discipline is essential for DevOps to be effective, and this can be a struggle for those who are unaccustomed to such a free flow of information.
DevOps works well with a development team that is already agile – fast iteration cycles, flexible scope and a dedicated long term ‘burn rate’ (or resource allocation). If your team currently works in a waterfall or fixed scope model, introducing DevOps will need broader business support to change the way the team works, otherwise it will feel like progress has slowed and functional targets are no longer being met.
…but it’s time to tie the knot
In any adjustment to working practices, there are bound to be concerns that the new way is going to cause more problems than the way you’ve always done things. But, with the fast pace of advances in technology and the ever-increasing demands from businesses who understandably want to keep up, a new, more collaborative and communicative way of working is the only way to move forward. DevOps is in it for the long term – a relationship built on trust, talking and mutual respect.