DevOps is changing, and some are challenging “shift left” management

Source:-techrepublic

TechRepublic’s Karen Roby interviews Checkmarx’s Matt Rose about the possibility that “shift left” is no longer the gold standard in DevOps, and that agile is more than just a verb.

Must-read Developer content

• 10 ways to prevent developer burnout (free PDF)
• How to become a developer: A cheat sheet
• Developer pay: Here’s how salaries rise with experience across programming languages
• Python is eating the world: How one developer’s side project became the hottest programming language on the planet

TechRepublic’s Karen Roby discussed “shift left” with Matt Rose of Checkmarx. The following is an edited transcript of their interview.

Karen Roby: Matt, thank you for being with us. Tell us why you think that the idea of “shift left” management needs to be re-evaluated. 

Matt Rose: It’s kind of an evolution in the space of software development. If you go out and google “software development life cycles,” they’re depicted as a linear or a sentence–they have a beginning and an end. But with the adoption and the maturation of DevOps, it’s now an infinite loop that’s constantly moving. So there really isn’t a left or right anymore–there’s just the process, and the DevOps process is a living, breathing thing. So there really isn’t a left to identify. I’m not saying shift left is dead: I’m saying let’s repurpose the left for something more practical. So, it’s more around remediation and verification than it is on identification. The middle or continuous integration is really where you automate the process of implementing security technologies in DevOps, and that is the fuel for the rest of the program.

SEE: Project Catalyst: What developers need to know (free PDF) (TechRepublic)

Karen Roby: Expand for us, if you will, on how DevOps has changed, in your opinion, to support the idea that shift left shouldn’t be considered the gold standard anymore.

Matt Rose: With DevOps, we’ve changed the way we’re developing software. You used to do a release every month or every couple months. Now larger organizations are doing hundreds if not thousands of builds a day based on the new technologies and new capabilities around microservices and web services and all these types of things. So education for new software engineers or legacy or very mature software engineers has to change as well. The reason being is that older software training or application security training, you go to a class and you’d sit in a class for eight hours and you’d be out-of-band, and it would be out of context, and you’d be drinking from the fire hose. And then you try and take that back to your day-to-day activity in terms of writing code, and it just didn’t map.

So, really thinking about in this kind of like, art imitating life or business imitating life, you need something like, “Hey, I have to fix this security issue. I need a modular component that’s very structured and very easy to digest to fix this vulnerability.” Not only does the landscape of the development need to change the implementation, the overall understanding of how to fix it needs to change as well. You can’t go to a class for a week and then really be effective in terms of fixing risk. Where if I have a problem, I want instructions on how to fix it. You have to change the way training is to map to the speed of DevOps.

Karen Roby: I know not everyone agrees with your stance on this here, and we certainly appreciate you sharing your insight with us. Any final thoughts?

Matt Rose: DevOps is introducing a lot of new concepts to not only the software development world but also security world. And we’re really living in a world of acronym soup right now. I mean, everyone’s mentioning DevOps or DevSecOps or SecDevOps, or implementing a CI or CD environment, continuous integration, continuous delivery, continuous deployment. As people start going down this path to implement a leading edge DevOps program process, whatever you want to call it, they need to truly understand what they’re talking about because I hear acronyms being misused. I hear processes being misused. People just jump on the bandwagon and like, “I sound really smart that I know what a DevOps is.” Or, “I throw out CI/CD and Agile and I feel like I’m totally vetted in this.” And I like to kind of open the hood and really understand what they’re talking about. And a lot of times they don’t truly understand. They’re just jumping on that bandwagon and just saying the things to sound interesting or intelligent.

My favorite thing is the overuse of the term agile. It’s used everywhere, and I hear it, and it makes my skin cringe. “Are you talking about agile verb or agile noun?” And people look at me very strangely, and they say, “Well, agile DevOps.” I’m like, “What does that truly mean?”

Agile to me is, are you flexible to change? Are you flexible to your customer requirements, to your program manager’s requirements? That’s the verb version. “I’m flexible. I can do a backbend, I can shift or pivot really quickly to meet my customer’s needs.” That’s the verb. The noun is actually the software development methodology called Agile, and all the capabilities and terminologies associated with that. Truly understanding what agile means to you and your organization really helps an organization and its stakeholders to truly figure out the best practice in what they’re trying to do.

Executive Briefing Newsletter

Discover the secrets to IT leadership success with these tips on project management, budgets, and dealing with day-to-day challenges. Delivered Tuesdays and Thursdays Sign up today

Also see

• How to become a developer: A cheat sheet (TechRepublic)
• Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)
• Telephone interview cheat sheet: Software developer (TechRepublic Premium)
• Programming languages: Developers reveal most loved, most loathed, what pays best (ZDNet)
• It takes work to keep your data private online. These apps can help (CNET)
• Programming languages and developer career resources (TechRepublic on Flipboard)