Out with the old, in with the new? Not quite!

Addressing the skills gap between new and older DevOps specialists

Viktor Farcic

© Shutterstock /  studiostoks

We need to merge the new and the old if we are to improve and survive in today’s market. Otherwise, we are facing extinction because new and better ways of thinking come along. In this article, Viktor Farcic, Senior Consultant at CloudBees, explains why we need to combine experience with innovation.

We’re only a few years into the DevOps movement (at least under that name) and people have already started making a distinction between the old-timer DevOps specialists and newbies. The problem lies in a misunderstanding of DevOps. That is evident when looking into job offers. The demand for DevOps Engineers is higher than for any other profile. That would be great news for DevOps engineers if it would not be for the fact that there is no such thing as a DevOps engineer. Think about it. What is the difference between, let’s say, a sysadmin and a DevOps engineer? None, whatsoever. The same teams that were, in the past, in charge of operations or CI/CD processes and automation are now re-branded into DevOps teams. Everything is the same but the name is different. Well, that is not what DevOps is.

DevOps is about bridging the gap between developers and operations. It is about the removal of the silos and collocation of those specialties into self-sufficient teams. It is about changing the culture. We can think about DevOps as a continuation of Agile practices.

Agile tried to remove some of the silos. If we exclude the teams that are “faking” Agile, business analysts, developers and testers are now working as one, coherent group. They are all members of the same team. Horizontal departments gave way to teams organized around products, not their specialties. Agile tried to remove lean time created by handoffs from one department to another. The problem is that Agile excluded operations, sysadmins and other expertise that comes in later stages of the software development lifecycle. It’s not that Agile excluded them explicitly, but more that the practical implementation left them out. They were not invited to the party.

DevOps tries to fix that by extending the reach to previously excluded specialists. It includes operators and sysadmins into autonomous teams thus making them truly self-sufficient. A team should be in charge of a service from the beginning (a commit) to the end (deployment to production and monitoring). Agile renamed roles (e.g., project manager becomes product owner) while DevOps does nothing of the sort. You continue being whatever you are, but you’re moved into the team formed around a product. You do not belong to a department anymore. Your goal is not different than goals of other members. The whole team has only one objective; to deploy something to production with high quality and fast.

Let me go back to the initial question that asked about pros and cons of young/new and older DevOps specialists. Knowing that DevOps is not a role but a cultural shift, the question itself is invalid. It should be changed to pros and cons of young/new and older specialists (without DevOps). Even though the difference is in a single word, it is an important one since it allows us to focus on people expertise, not the false assumption that someone can be re-branded to a DevOps specialist.

SEE ALSO: DevOps transformation essentials: “You cannot improve what you cannot measure”

Fresh blood tends to introduce new views to the company. That is unless they are immediately put into a box that does not allow them to express themselves. New, less experienced professionals are not restrained by their prior knowledge and can think out of the box. Further, they don’t know the old ways – they can adapt to any way of working. DevOps to them is the normal way to work. They aren’t encumbered by the past.

Those of us who spend a lot of time working in the same environment tend to become complacent. We tend to learn “the best” way to do things. The problem is that there is no “best” way and, even if there is, it changes constantly. Best practices tend to have a very short lifespan since the technology and processes are changing with an ever-increasing speed. And yet, sooner or later, most of us become slaves to the way of doing things that we are used to. That slavery prevents us from adopting new and better ways to do our job. Advancements are often introduced by those who are capable of having unconstrained ideas. Those people are often newbies. Still, they have their own set of problems.

Being less experienced means that we do not (yet) possess the knowledge required for working in complex environments. Everything seems easier than it is.

For example:

  • Misperception: “This application can be rewritten in Go in a few weeks time.”

Reality: Probably not. Unless it is a very simple application.

  • Misperception: “If we move to microservices, all our problems will be gone.”

Reality: Definitely not. Migrating your application(s) to a microservices architecture just might be a very significant project, in itself. Additionally, even when you are done, you will never eliminate all issues. But hopefully, you will have a more resilient, robust, easily upgradable application(s).

  • Misperception: “Docker will solve our scalability issues.”

Reality: Yes, sort of. If used correctly, it will help. But if your environment is such that you have resource constraints…Docker can’t solve those. And what about dev v. test v. ops? If all three teams don’t embrace Docker, then all is for naught. Of course, if teams are that siloed, you aren’t in a DevOps environment anyway!

SEE ALSO: What is the true cost of a DevOps adoption?

These are only a few of the examples that look much easier to implement than they often are. Yet, it is no surprise that such suggestions are coming from less experienced professionals. They have not yet had the chance to truly grasp the complexities of a system. Even if it’s a greenfield project that just started, experience tells us that it will become much more complex with time and that complexity needs to be taken into the account early on.

This is the generational conflict that can be seen everywhere, not only in the software industry. Less experienced professionals are more likely to bring new ideas to the table but lack the experience to implement them successfully. More experienced people tend to get locked into their experience and refuse innovation. We need both. We need to combine experience with innovation. We need to merge the new and the old if we are to improve and survive in today’s market. Otherwise, we are facing extinction because new and better ways of thinking come along. And whether it’s DevOps or something else, we need to be open to new ideas and new ways of doing things.



Viktor Farcic

Viktor Farcic is a Senior Consultant at CloudBees. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .NET suffix), C, C++, Perl, Python, ASP.Net, Visual Basic, C#, JavaScript, etc. He never worked with Fortran. His current favorites are Scala and JavaScript even though most of his office hours are spent with Java. His big passions are microservices, Continuous Deployment and Test-driven Development (TDD).

Inline Feedbacks
View all comments