There’s this urban legend going around…

A young developer was joining her first big new job. It was the first time she would be on a big team, with lots of teammates, no longer working by herself and having to do everything on her own.

It was one of those old companies. You know, the ones here before people even had computers in their homes – still a giant but not known for their innovation or willingness to risk it all on new ideas.

On her first day, she came to a rude awakening: there was no room for her in the giant and crowded office. Not only was she not going to be working closely with her team, but she was cast out to work at “the annex” at a different building, right next to the system administrators.

When it comes to app development, be it web or mobile, it’s all about unimaginable complexities. The basic fundamentals like writing the code, testing it, debugging, and later deployment are present all of the time. 

All these responsibilities need a specific team of experts like developers, QA engineers, and system admins to carry them out. So, it’s like a well-defined hierarchy of labor where every team and its members have something different to focus on. Developers hustle hard to add as many features as they can. QA teams stress about working around flaws and making things work out. System admins have their own woes of keeping the whole thing up and running smoothly at all times. 

Everything seems to be subtle until some problem arises. Let us suppose an issue arises and a bug is found in the piece of code. The seemingly smooth development cycle will turn chaotic with questions like who should fix the erroneous piece of code and how soon things will be back on track. Generally, if anything troubles the production servers or deployment, the admins are the first respondents.

 When she came in and said hello, no one really answered. A few of them looked away from their monitors and returned to whatever they were doing. Even among them, there were no real conversations, just a few questions with somebody responding right away.

WHO messed up my config on the DB server?”
— “I FIXED your config on the DB server, if that’s what you’re talking about.”

At lunch, her new teammates welcomed her, but also poked fun at her for her unfortunate position: a young developer surrounded by the enemy. They shared stories about these “administrators,” how they were always grumpy, did not like the dev team, and how they felt as if the servers were theirs to control and use as they see fit.

If the issue has something to do with the code, the task is passed on to the developers. Then, it’s up to these coding ninjas to figure out how to fix things and pass the baton to the QA team for testing. After all this, the tested piece of code is sent back to the system administrators for deployment. 

So, in such a workflow, even a tiny problem could create a substantial amount of mess. Moreover, as the number of new releases increases (which is the actual case), the whole matter may turn disastrous.

They saw the operations team as the worst. They only care about uptime, and they don’t like innovation. It’s like they would be happier if all of them would disappear.

With an issue that is still unresolved and plenty of features scheduled to be released, things would surely get out of hand. Situations like these often lead to differences across teams. They might even start the blame game. Everyone, starting from developers to system administrators, would think that it must be the others who started the whole mess.

Some time passed, and she was getting used to the job. She was making progress, her team was great, and she even got on friendly terms with the admin sitting next to her. Of course, it was not like they were friends or anything, but at least they both acknowledged each other’s presence. Even one time, he called for her that she was forgetting her car keys and saved her some time!

She was part of the team in charge of one of the most important applications the company hosted. The application itself was not bad, but making changes to it took forever – approvals upon approvals, and nobody wanted to deal with the admins.

She used to be an admin when she was working by herself. She had to do it all. Unlike her teammates, she understood the importance of stability. Even though she was not really part of the admins, and most of them didn’t even notice her, she sometimes felt like it was her duty to defend them when talking with her colleagues.

On a psychological level, such a scenario often leads to distrust resulting from a prolonged gap in communication between teams. Such a conflict of interest turns the simple software development cycle into a nightmare. As a result, businesses may lose a lot of money and valuable time.

After a couple of years there, the developer felt right at home. She participated a little bit in the banter about the admins, and they even invited her to their bowling tournament. She had become friends with the guy sitting right next to her, and they often did favors for each other. Little did she know, something was going to happen soon that would change history forever (?).

A couple of weeks had passed after a major upgrade to the application. She had a significant role in pushing this, and “the powers that be” were very pleased with her performance, so they decided to assign her a project… a solo project.

This add-on would assist the major app and leverage some of its components. Of course, it had to live with it, but, unlike other projects, time was of the essence. If they wanted this project to succeed, it had to be fast.

She knew the main application back and forward. She was the right person for the job, but there was just one big problem: making changes on the server that hosted the main app would be super slow. She knew the change management process would slow her down and potentially make this project fail, but she also knew her friend, the admin, had all the necessary clearance to make the changes she may require. So, if she could get him on the team, this project may have a shot.

Back then, operations and development were entirely different entities. With their own organizational chart and their own way to do things, getting her friend on the team was not going to be easy.

Searching for a Solution

The drawbacks of Waterfall led to businesses coming up with changes in their own way of handling things. This slowly evolved to become what we know as the Agile methodology

It is believed that the term Agile software development was coined somewhere around 2001. With Agile, developers could launch projects much faster with improved teamwork and better cross-functional abilities.

Even working in more demanding and turbulent environments, the teams could now respond to changes better. One major thing that separates Agile from other software approaches is its focus on the people doing the work. Everything revolves around constructive collaborations and practices based on the situation at hand.

The first pushback was from her team. How could she possibly prefer to work with an admin instead of another developer? The second one was from her boss: “How could you possibly make progress with an admin checking your every move?” And the third one was with the admin’s boss: “How could we possibly afford to give you an admin for just one project? We can barely manage as it is.”

The idea was unheard of, but the project had a big sponsor from the top of the food chain. After she explained her idea, they had no choice but to give in to her demands.

The last pushback was one she didn’t expect. It was from her friend, the admin. He was angry at her; his boss told him he was still supporting all the other projects on top of this and that he was responsible for protecting the infrastructure, any issue, and it was his head on the cutting board if something went wrong.

The self-organizing teams tend to focus on clients’ needs, and there is plenty of room for changes throughout the process. However, something was still missing. Agile was fine, but it couldn’t be labeled as perfect. Despite close collaborations, Agile still lacked on a few fronts.

She talked him down, saying she would help and would only bother him when she really needed it. After that, the project was a go.

Developing and testing was rather business as usual, but when they needed to upload the changes to the production server, they needed the admin’s help.

She was on fire, delivering feature after feature. With his help, both managers and clients could use this software almost immediately. There was just one problem, every time they had to push to production, the admin was involved, and he was starting to neglect other projects. He was not happy.

Mostly, developers had to handle most of the pressure, and system admins had little room to contribute. Moreover, projects could easily fall off track due to a lack of proper documentation and rigorous commitments. So, something had to bridge all these gaps.

Seeing that, she took on a side project: she started to write a script that would help him push to production faster. It wasn’t pretty, but it worked, and she quickly shared it with her friend.

The Inception of DevOps

The history of DevOps is simple yet revolutionary. The concept of DevOps emerged out of a discussion between Andrew Clay and Patrick Debois in 2008. They were concerned about the drawbacks of Agile and wanted to come up with something better. 

The idea slowly began to spread, and after the DevOpsDays event held in Belgium in 2009, it became quite a buzzword. What’s great about DevOps is that there is more to it than it seems. It’s not just an attempt at efficiency; it is a step towards cultural change. We can call it a blend of agile philosophy with lean thinking.

He was a bit shocked at first. The script looked great, and he liked automating things, but he never thought of some of the items in the script. On the other side, it was really rudimentary. No checks whatsoever on the infra, and it assumed a lot. But in the end, he loved the idea, and it cleared his plate to do some work on the other projects. So, she could continue with her work uninterrupted.

Whenever the admin had a chance, he would work on the script to make it better and more secure for the infra. She also worked on the look and feel of the script, so it would be simple to customize using buttons, checkboxes, etc.

DevOps unites the efforts of every team involved in the project with tighter integration. This cross-department integration between developers, QA engineers, and system admins is more impressive than it sounds. 

DevOps implementation ensures that developers can now take part in deployment, admins can write scripts, and QA engineers know how to figure out issues other than testing. In addition, processes can be automated, and no one has to wait as they can now work more closely to develop quicker and better solutions. 

Better communication and understanding would also help teams to recognize the priorities each other has. And all of these benefits would mean skyrocketing productivity and swift delivery speeds.

After a while, they had this fully automated push to production that was so simple and customizable, even other projects started using it. It eventually integrated other functions, such as building the application or notifying certain people about progress or errors. And that, my friends, is how a new breed of computer engineers was born.

What they did without even realizing it was become DevOps engineers: developers that understood the need for admins (operators) and admins that understood the need for developers by adopting each other’s abilities and creating a better, faster development cycle.