In over two decades in the industry, Edwards had seen a colossal shift in DevOps. She likened the shift between modern and legacy applications to the difference between pit crews for Formula One racing. 

In a video clip illustrating the point, we see a group of four people servicing a car mid-race in the 1960s, taking over a minute to do so. “It’s slow. It’s like watching paint dry watching them service that car, just like our legacy applications,” said Edwards. 

Fast forward to modern day Formula One pit crews, who can complete a pit stop in an average of less than four seconds. The difference, according to Edwards: more people.

More people working together, or simply supervising the workers looking for areas of improvement has led to vast improvements in both the quality and speed of the pit stops overtime, making it the perfect allegory for DevOps in today’s software development approach. 

What is DevOps

DevOps is the union of software development (Dev) and information technology operations (Ops). As Edwards puts it, DevOps is the fusion of people, process and products to enable continuous delivery of value to end users. 

The implementation of DevOps can lead to 973 times more frequent code deployments, 6,570 times faster commit to deploy lead time and 2,604 times faster recovery from incidents, according to Edwards. However, without proper security implemented into the DevOps pipeline, the rapid deployment and continuous integration can lead to security vulnerabilities.

Building a system that is secure for the user in today’s landscape begins, as Edwards puts it, with “eating your own dog food, or drinking your own champagne, it feels better.”

By this she means to truly understand the pressure points being felt by your customers, you have to become the customer yourself. By using your own product, in this case GitHub, means you have to adopt a “customer obsessed culture,” shifting the onus of a product on how it will serve the end user whose needs are constantly changing, and all the teams involved need to do this together. 

Changing the definition of ‘done’

Doing this, for the team at GitHub, meant changing the definition of done. A lot of this shift comes from the change to delivering boxed software products to cloud-based products. Meaning, if a customer is experiencing an issue, it is not simply up to you to help them fix it, but is now up to you to address the underlying issue that caused the problem. 

This also means spending more time getting it right in the beginning. When building a product, Edwards says to think “this isn’t going to a test environment, this is going into production.

“We’ve changed how we collaborate and how we work together in the hands of security, from development to production, security comes from day one, it comes from our developers, security starts when your developers plug in their code.”

Enabling this secure, customer centric product involves iterations of the same product. For example, the original Microsoft Team Foundation Server (TFS) – which is now the Azure DevOps server –  took 18 months to build and another 18 to ship. 

Now, Azure is doing deployments every three weeks, in the time span Edward calls the goldilocks principle. This is finding the optimal amount of time your team needs to identify what needs to be changed, and giving the update ample time in development and review before releasing it. 

Recommended

• Cloud First 2023 | Your Guide to Data Protection Regulations
• Scotland Outpaces UK and Europe for Foreign Investment
• Report: Twitter Ranked Most Dangerous Social Media for LGBTQ+ Users

Horizontal to Vertical Engineering

To pull this off, they shifted their product mindset from ‘horizontal’ to ‘vertical’, as Edwards calls it. Horizontal is separate groups spearheading user experience (UI), application program interface (API), and data. Whereas Vertical product mindset has groups spearheading small portions of all three together.

“We have to own the product, from inception, to production, we own it all in the full DevOps lifecycle, the planning, development, deployment and monitoring,” said Edwards. 

This practice involves taking on tasks that are outside of your comfort zone. Instead of being an engineer in one specific domain like C#, security or AI, everyone was a software engineer assigned with outcomes and key results. 

The practice of vertical engineering, focused on customer centric outcomes, was a challenge to overcome in the remote work world, but also inspired teams to come together in the name of a better end product. 

Initially, Edwards said, “I felt like I was the one slowing everyone down,” however it was the whole team that was taking on tasks that they were less comfortable with. To overcome this, their team implemented office hours. 

She adds: “We would literally open up a team or a zoom call, and we would just talk it out,” she said. Meaning when one engineer hit a snag as part of their vertical approach, they would be forced to collaborate with other engineers to solve it, bringing everyone together to share their strengths, and build their peers up with them.

“People all come from different places, so it’s great to have that camaraderie”

“We also do brown bag learning, so everyone brings lunch, they come to that, and we share our learnings,” she said. “I had a junior engineer on one of my teams, she just learned (GitHub). She’s like, ‘Oh, I don’t know, I haven’t really talked about it.’”

Talking about how the young engineer thought she would have nothing to offer the team, with regards to describing the experience of learning a tool they already knew, Edwards says: “I said no, I want you to talk about it because you’re gonna teach me something.

“In the end, the junior engineer did bring new insight to the table since they had fresh eyes on a product everyone else was already set in their ways with.”

This means that the process of vertical engineering doesn’t just benefit those who don’t know a way of doing something to learn how to do it, but also helps the engineers already well versed in a specific method to gain insight from a fresh perspective. 

DevOps in the real world brings value to the end user in consistent iterations and user centred design. However, it also forces the engineers to widen their horizons and become better themselves, which in turn, will only improve the product for the end user.