Tag: software development

  • PlanSecOps: Incorporating Security Strategies in Design

    PlanSecOps: Incorporating Security Strategies in Design

    Organizations that don’t adapt and change aren’t likely to survive. The same can be said about DevSecOps, a discipline created to ensure security is baked into the software development process, not an add-on after the code is approved. And as much as DevSecOps has changed the software development world for the better, it is time to evolve DevSecOps so that security is considered even earlier in the application development process—before a single line of code is even written.

    We are already seeing glimpses of this early marriage of security and software development. Security is starting to be implemented from the initial design through integration, testing, deployment and software delivery. I’ve taken to calling the process PlanSecOps.

    What is PlanSecOps?

    With DevSecOps, developers integrate security measures into the code, then test to ensure it works. PlanSecOps starts the process earlier in the development cycle, incorporating security at the planning stage before any code is written. It’s easier to incorporate security fixes during the development cycle (i.e., before the coding phase) by including security pros who know from experience what kind of vulnerabilities exist in different types of software during the planning and architecture cycles.

    Consider the process of building a house. Adding a hard-wired security system after the house is built usually requires some retrofitting with the aid of an electrician and contractor to install the system in a manner that doesn’t interfere with other parts of the electrical infrastructure. However, if a security system is part of the house’s blueprint, it’s ready to go when the build is complete with no risk of incompatibilities. PlanSecOps does the same thing for the development process.

    PlanSecOps is a More Holistic Approach to Security

    Companies want to grow, innovate and move quickly to deliver new functionality to improve the customer experience. It’s how they remain competitive. Shortening development cycles with Agile methods and DevOps teams helps them move faster.

    Yet, attack strategies are only getting more sophisticated, and hackers are ready to jump on any vulnerability in an app. Like the game whack-a-mole, DevSecOps looks at individual pieces of code and applies patches. As soon as one vulnerability is patched, a never-ending set of new exposure points pop up. Fixing one problem may undo the patch for another, making each new issue more complex to address.

    PlanSecOps is a more holistic approach to security by design. It’s putting a system in place versus just fixing issues as they emerge—patching different subroutines and making sure they all work together. PlanSecOps simplifies coding and testing to ensure functionality. It also simplifies the process downstream for the engineer, providing a faster, easier and more sustainable development process. It can cut weeks out of the development cycle.

    Recommendations for Implementing PlanSecOps

    Security patching is increasingly impractical in the development phase because of its complexity and the impact of privacy regulations like GDPR. Having one overarching strategy for data privacy is a better approach than trying to retrofit it into software after the coding phase. While this oversight is possible to handle in-house, it requires either one privacy engineer with a legal background and experience in software development or a team that covers all of this expertise. Both options are costly. Additionally, tech talent is challenging to recruit right now.

    While at the RSA conference earlier this year, I saw several new companies that are creating security platforms designed to make security-by-design easier. These tools grade your code and provide a framework for the development process. Gathering this data could be a good start to identifying any issues, but you still need an expert who is smart enough to enact fixes based on the information the tool provides. Additionally, it’s difficult to vet which tools are right for your dev process. For example, a tool designed for the health care industry wouldn’t be applicable to a manufacturing application.

    Alternatively, you could partner with organizations that have a security-by-design approach and are already handling security planning during the architecture phase. Partnering with software development companies like this is typically less expensive than hiring someone in-house. Plus, you’ll get the experience you need to bake security into your applications from the beginning.

    Security Needs to Start Early and Never End

    October was cybersecurity awareness month and reminds us that cybersecurity is everyone’s responsibility. To stay competitive, companies need to embrace that responsibility and address the ever-evolving security risks at the beginning of DevOps cycles. The software development journey has no end because new features will always be needed and new technologies will emerge. The key to success is to ensure that everyone in the software development process shares accountability for security and that all systems are as automated as possible. With improved collaboration and understanding of risks, organizations can better respond to both cybersecurity risks and software development innovations as they look to the future.

  • Understanding the Importance of Developer Experience

    Understanding the Importance of Developer Experience

    If you’re creating a developer tool, you’re bound to run into this dilemma—you know the inner workings of it really well, but others don’t. And without solid documentation and samples to follow, it can be challenging for another person to get started. Friction with the tools we use can contribute to burnout, inhibit creativity and slow down innovation.

    Developer experience (DX) is becoming integral for any software company to consider. I recently met with Christine Spang, CTO and co-founder of Nylas, to consider the benefits of investing in developer experience. Below, we’ll take a look at what exactly DX is and consider some best practices for implementing it.

    What is Developer Experience?

    Developer experience (DX) is similar to user experience but for developer-facing tools. DX considers the developer’s journey while developing with a certain framework, language or platform. “Developer experience is the amount of friction a developer experiences between having clarity on what they want to implement and getting to the point where you have created that thing,” said Spang.

    For example, consider integrating with an API to solve a common use case like payments integration. There are many steps involved here, from reading the reference documentation to getting an API key, testing calls and understanding how the service responds. After developers initially integrate the API into their application, they may also have to make continual updates as the service versions. Throughout this journey, DX can be thought of as “how hard it is to figure out how to translate from idea to output,” said Spang.

    It’s also important to note that DX isn’t only relegated to public-facing platforms. Having a quality developer experience is just as crucial for internal software. The urgency to improve internal developer experience is increasing with the surge of APIs being developed, especially since the majority of them (58%) are private APIs, according to Postman’s 2022 State of API Report. Depending on the size of a company, internal DX can encompass many areas.

    Best Practices for Investing in Developer Experience

    So, what are some methods to improve developer experience across the board? Well, having up-to-date documentation, code samples, better examples and standardized documentation rank high as positive developer experience traits. Spang also shared some helpful best practices to improve DX:

    Provide scaffolding for the most common cases. Measure patterns around the kind of things people are building with the platform and offer scaffolding to support the common use cases. This might equate to a getting started guide for a common scenario.

    Offer sample code libraries. It’s a lot easier to edit code than write it from scratch. With that in mind, create pre-baked environments where developers can play around. Offering working apps, use case templates and glue code can be a practical means to help developers get going more seamlessly.

    Start with the reference manual. Walkthroughs and sample code should never replace a complete reference manual. It’s essential to have up-to-date documentation to cater to advanced users from the get-go. From here, you can generate Postman Collections or interactive sandboxes built around the reference specification.

    Measure DX success and iterate. One way to monitor developer experience metrics is to record the onboarding flow and measure conversion rates. Where APIs are concerned, this can be tracked by asking how many people get through to making calls? What is the mean time it takes to make the first call? Knowing such metrics can inform how effective your tool’s self-service features are.

    One point that’s important for DX is walking the fine line between too much custom work and focusing on the core project. On that note, Spang recommended “making sure whatever you’re building maps to the overall vision of the company.” In essence, if you’re not a consulting shop but a product company, you should stay true to that objective.

    “You want to make the path for what people commonly want to do very easy,” said Spang. “Yet, you don’t want advanced users to feel constrained by the platform.”

    Examples of Quality Developer Experiences

    For those creating developer-facing services, it’s helpful to have a framework to model. So, what are some examples of quality developer experiences?

    Well, top public APIs are great examples of where the bar is set for developer expectations these days, said Spang—services like Twilio or Stripe demonstrate relatively seamless developer journeys. Spang also pointed to companies with a strong DevOps and CI/CD background, like Etsy, who have for years invested in usable backend infrastructure that accelerates internal development.

    For other sources of quality developer experience, consider the high-ranking developer-favorite technologies from the latest 2022 Stack Overflow survey. Engineers love working with technologies such as PostgreSQL, AWS, Phoneix and Docker. The newer, trending languages tend to be increasingly usable, too. For example, 86% of developers said they love working with Rust while 76.65% dread working with Objective-C.

    The Overall Benefits of DX

    An investment into developer experience can help improve agility and developer satisfaction, said Spang. For one, an easier path for development increases the velocity in how you ship and evolve projects over time. Secondly, developer experience equates to less burnout and less turnover, both of which can have real business impacts.

    The software development industry is growing like wildfire, bringing in waves of entry-level developers each year. Interestingly, the average experience level is decreasing, increasing the need for more abstracted tools and toolkits, said Spang. In this environment, developer experience undoubtedly shines as a competitive advantage.

    So, if you’re creating developer-facing tools, consider the experience others will have when using them. Increasing developer experience may just be a defining factor in the project’s success and the long-term happiness of your developer community.

  • Techstrong TV: Recruiting Developers with the Right Skills

    Techstrong TV: Recruiting Developers with the Right Skills

    The biggest challenge facing the software industry is recruiting developers with the right skills, according to a Reveal’s third annual “Top Software Development Challenges for 2022” survey. Jason Beres, SVP of Developer Tools at Infragistics, and Charlene discuss how organizations can address these and other challenges effectively. The video is below followed by a transcript of the conversation.

    Charlene O’Hanlon: Hey everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon and I’m here now with Jason Beres, who is the Senior Vice President of Developer Tools at Infragistics. Jason, thank you so much for taking a couple minutes and getting on the Zoom with me. I appreciate it. 

    Jason Beres: Thanks for having us, Charlene. Thank you.

    O’Hanlon: So I’m interested in talking with you a little bit about what you guys have seen over the last, I would say, year, year and a half of so, as it relates to developers, the great resignation, and the lack of qualified developers filling the roles these days, and the impact that that’s having on developer organization, especially as it relates to tools and tooling. So I wonder if we can set the stage a little bit, though. So, let’s talk about what you guys have seen in the market over the last year or so, as it pertains to the developer ranks. Are we seeing a lot of folks moving around?

    Beres: Yeah. It’s interesting, and the impetus to this interview is we just got a survey results back that we did. It went over a six week period, and we asked a lot of questions about what’s been going on in the last 18 months with developers. And this is a huge issue. It’s a huge issue for everyone, this lack of skills needed to move digital transformation forward. So developers are maybe looking at other career opportunities, maybe there’s new thing in the development space they want to do vs. what they did in the past. Maybe they don’t want to be a full staff web developer anymore, they want to get into AI, machine learning. And so there’s pockets that we see which are really having a hard time hiring. And you’re looking at numbers of 50 to 60 percent of companies having trouble finding skilled developers for positions. And Infragistics is no different. We’ve had positions open for almost a year for some job openings, and we have offices globally. We’ll hire anywhere. It’s a huge challenge, and I think it’s shifting the way organizations think about application development and tooling, and what they really need to move forward.

    O’Hanlon: I keep hearing about the great resignation, and the fact that everybody … not everybody … but a lot of people are rethinking where they want to be in life. And so they’re moving on to doing different things. But I almost feel like there’s got to be someplace where these people are going. So, is it really the great resignation, or do you think it’s just the great reshuffling? 

    Beres: Oh, wow. That’s a good way of putting it. I do think it’s a great reshuffling more than resignation. I think there’s pockets of the economy where it’s no doubt the great resignation. My brother is CFO of a trucking company. And they see that a lot of the truckers who couldn’t truck during the pandemic just retired. Or they’re like, “Man. Trucking’s really hard. I’m gonna go do something different, where I’m not on the road 60 hours a week.” So I think certain pockets of the economy are more affected than software developers, but I think software developers are the type of folks that need a challenge. So they’re always looking to be having the next big thing that maybe is not necessarily resume padding. It’s more about I need to be challenged more, and I’m looking at other options. And, by the way, I can get a 25 percent raise doing it. That’s … I think what’s driving it is you see big tech … The interesting thing is, right now what you see is, in terms of Meta, for example, the Metaverse, big tech is just … they’re taking people from each other now with ridiculous salaries. So where a guy might have made X amount, they’re offering three times that amount to go between Facebook, Google, Microsoft.

    So, in a smaller business, I don’t think it’s as bad as that, but it really depends where you’re at. Infragistics happens to be headquartered in New Jersey, or a 45 minute train ride into New York City. There’s a lot of big tech in New York City, so folks are really, “Hey. Should I take the risk? Can I still work from home?” Now work from home is a big benefit, and I think one of the risks that big tech sees is, “Well is that … hey we’re gonna make folks start coming in the office.” And a lot of people are like, “No, please don’t make us do that, or I will look elsewhere.” So I think the great reshuffle maybe is a better way of putting it, as you’ve described, in software development specifically.

    O’Hanlon: And I also see that a lot of developers, over the course of the pandemic, they used a lot of their … I won’t say free time, ’cause I don’t think anybody really had free time, but they were using some of their down time to really up level their skills. And so they’re shifting now into newer areas of development where, to your point earlier, maybe they’re more interested in AI. So they now have that skill set to be able to do that. So are you guys seeing that there are certain levels of developers, or certain areas that are seeing larger pockets of open positions over others? Are we looking at more entry level positions that are not being filled these days?

    Beres: I think what we’re seeing, and again, we have offices all over the place, in the US, in South America, in Eastern Europe and Western Europe, in Japan, and in India. And each one of those offices has unique problems. So, for example, in South America, I think we’re seeing just the development skill levels are continuing to rise. So maybe five years ago you could hire a lot of really junior people, and you could get them for less money. Now you’re hiring more senior people who are looking for a little bit more money, but they’re looking for more of a challenge. I think there’s more junior people maybe in locations in Eastern Europe that we didn’t see before, but the risk there is you hire someone who’s junior, and then they’re gonna jump ship relatively quickly, maybe in a year, maybe in 18 months, once they feel like, “Hey, wait a minute. I can go make life changing money, which might be a 20 percent raise when you’re in your early 20s just out of school, but that’s like a big stepping stone for you moving forward.

    So I do see that it’s challenging in each location. But at the same time, I think everyone up leveled. If you’re serious about your career, you did have more time last year, and the year before. You weren’t on the road for an hour, hour and a half. Folks that used to work in New York, as you know, would spend maybe two to three hours in a train, jammed together with other people, and they couldn’t even read a book. 

    O’Hanlon: Yeah. Been there, done that.

    Beres: So now they’re at home, and they’re taking free courses. And so you look at some of these training companies, even LinkedIn Learning, they’ve exploded in the last couple years, among others. And there’s training companies that ten years ago were nothing. Now they’re billion dollar companies, because of online training. And so I think if you’re serious about your career, you did up level, and you’re looking for other opportunities. Another one I didn’t mention before is Data Science. Data Science happens to be just exploding, of course, and maybe three to five years ago there were no data scientists. They were so hard to find. They were all career switchers. Maybe I was a really analytical guy, so I’m gonna try out this data science. Now, they’ve learned. Data Scientists are there, but they’re making still the bigger money. So it’s interesting how salaries have just shifted with the market over time as well.

    O’Hanlon: We’re seeing such upheaval everywhere. We think about the supply chain. We think about the people who are shifting jobs, and there’s so much in flux these days. It’s hard to pin things down. It’ll be interesting to see how things settle out over the next year or so. I think we are gonna see some settling over the next 12 months as, quote/unquote, things get back to normal, or somewhat sense of normal.

    Beres: We hope.

    O’Hanlon: Yeah. As we are seeing all of these things happening, all of these different forces at play, that’s gotta have an impact on the organization as a whole, beyond the human element. So what are you guys seeing with respect to tool sprawl, and other ways in which maybe the DevOps tool chain is being impacted, or just the whole developer experience is changing from an organizational point of view.

    Beres: I think what we do see is that the business is moving forward, no matter what. So businesses, and even in our survey, they’re looking at 10 percent growth, 20 percent growth. No one reported that they expect negative growth. They expect positive growth. And I think so many businesses … and it’s not just small businesses. It’s medium size businesses, and even like maybe silos in big tech realize that they were behind. So the pandemic said, or it really told them that they need to catch up. And so the business wants to grow, they want to move forward. So that’s when we start recognizing these gaps in skill sets and training, and things that we really wanted to do but we really can’t do ’cause we don’t have the people to do it, or we don’t have the right skill sets to do it, we waited too long. We didn’t move to the cloud. Well, why didn’t you move to the cloud? Gartner’s been saying move to the cloud for ten years, but you didn’t move to the cloud.

    So what happens is there’s more pressure put on dev teams, the backlogs get longer. So the way that affects the tool chain, the way that we see it affecting the tool chain in a typical enterprise, and even in SMB, is that tools like low code, no code tools are becoming more adopted, more trusted maybe. Organizations, IT is opening things up a little bit where maybe they’ll allow some APIs that maybe a marketing or sales team can use to do self service BI, or to create apps that aren’t business mission critical, but will help them be more productive. So we’ve seen a little bit of a shift there, and I think we see market growth there as well, in the last couple years, where the business of embedded analytics and low code, no code, were still in the billions of dollars, but billions of dollars in that upper scale, big tech. Now it’s being more widely adopted across the board and pushed down in SMB as well.

    O’Hanlon: Like I said before, I think we’re gonna see a lot of changes happening over the year as things settle down. Do you think that we’re going to see changes as it relate to how organizations actually choose their tools, and make the big decisions around that? How do you think that’s gonna be changing?

    Beres: So again, the pandemic taught everyone, you can’t be … you’re not beholden by the resources of IT as it is today. Or else you will be left behind. Digital transformation needs to happen, teams need to be more productive. You look at Microsoft and the explosion of Microsoft Teams, and this workspace collaboration. So, we see a growth in these types of tools. We see a growth of the number of people that are just gonna remain as a remote workforce, and then management, IT management and executive management at software companies is realizing that we need productivity. So how can we inject tooling that still give us what we need in terms of security, capabilities, user experience, but can move us forward in how we’re delivering applications internally and externally. So we see a lot of … before the pandemic there was a lot of talk about UX. So UX is top of mind in every executive meeting. But, did they really care about UX? Well now that everyone is, the consumerization has happened, your internal applications experience is just as important as your customer basing experiences. You need tooling that helps you do that more. So bringing in better user experience, tooling that can help deliver applications that look better, feel better, have a better experience, that are gonna drive internal growth, and obviously, external customer growth, really becomes critical and important. And in the next 12 months, in the next 18 months when things are starting to flesh out, these tools are here to stay.

    And again, there’s just not enough skilled workers. And if, for example, we can bring in a low code, no code tool to automate process and the super power user in the marketing or sales team, or even a junior dev can do it, vs. having to hire a team to build something from scratch, that’s where we see the savings, and that’s where we see this acceleration of the digital transformation in the enterprise.

    O’Hanlon: I really, really like the fact that over the past couple years, we’ve seen this whole democratization of just technology in general. And the fact that, to your point, somebody in finance or marketing or someplace an actually go in and make these changes, and in nine times out of ten actually get it done faster than if they had sent it over to the IT team to get it done. I think there’s really been a sea change, and it’s going to continue. How it ultimately impacts IT organizations, right now is pretty much anybody’s guess. But with the great resignation happening, and still happening, or the great reshuffling … I just like that word better … the great reshuffling happening, we’re gonna see a lot of changes, I think, to the way organizations view how they … not just how they utilize technology, but also maybe how they utilize their employees. That may be another conversation for another time.

    But Jason, thank you so much for having the conversation with me today.

    Beres: Thank you.

    O’Hanlon: And we look forward to having future conversations with you.

    Beres: Absolute. Thank you very much.

    O’Hanlon: Alright. Great.

    Alright everybody. Please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

  • Virtual Reality in the Workplace

    Virtual Reality in the Workplace

    Jonathan and Charlene discuss Moderne’s use of virtual reality—specifically, the Oculus VR system—as a collaboration tool for its disparate developer team and demonstrate how the groups works in the Workroom app. The video is above and a transcript of the conversation is below.

     

    Interviewer:                This is Digital Anarchist.

    Hey, everybody, welcome back to Techstrong TV. I am Charlene O’Hanlon, and I am here now with Jonathan Schneider, who is the cofounder and CEO of Moderne. Jonathan, thank you so much for getting on the Zoom and talking with me today. I really do appreciate it.

     

    Interviewee:                Always a pleasure.

     

    Interviewer:                So, I wanna talk to you about something that I’m super stoked about, actually. It’s the virtual reality and the way organizations can actually use virtual reality to their benefit. And I know your organization has kind of started doing a lot of your work in a virtual environment, in the Workrooms app on the Oculus, too. So, tell me a little bit about that, why you guys decided to go that route, and maybe some of the benefits that you guys have noticed with it.

     

    Interviewee:                Absolutely. I think it is good to say, upfront, that we started with a great degree of skepticism about this whole technology and approach, and I’m sure many of your listeners will, as well. I heard of podcasts three or four months ago, really, talking about how virtual reality could really start in the business first, and move towards more of a consumer use case, and I just needed to really understand. So, _____ we started small, we actually ordered one headset, initially, just to understand it, experience it, ’cause, you know, I’d never had any experience with VR. Then expanded it to two other employees, and it’s kind of gradually expanded since then. We just, we’ve been working on Zoom, our company is all remote, there’s 12 of us, we’ve actually never met in person, that’s probably not surprising, and we just felt a lack of presence and connection. So, it’s just a way of actually sitting together, and, surprisingly, that feeling comes across more than you think it would.

     

    Interviewer:                You know, it’s really interesting technology, and, you know, we’re gonna show the audience, in just a few minutes, exactly what it looks like and how you guys interact in the room. But, you know, it’s really fascinating to hear about the different ways that organizations are kind of dealing with this hybrid or all-remote work environment. And I remember, at the beginning of the pandemic, there were some companies that were trying to do standups in, like, Animal Crossing and different environments, just to kind of mix it up and make it seem like, you know, it’s not just like every day is an endless Zoom meeting. So, it’s really fascinating to me that we have kind of harnessed, if you will, this technology, and made it so much more than, you know, an endless Zoom meeting. And I wonder, when you guys set out to do this, I mean, were you actively looking for another approach to collaboration? Or is this just something that you guys decided, “Well, we’ll give it a try and see how it works”?

     

    Interviewee:                We did it opportunistically. I feel like more modes of communication are rarely a bad thing. You know, of course, we already had Zoom – really, it’s just, it was an inexpensive investment. You know, these headsets are about $300.00 each, relative to the cost of a laptop, which, you know, we regularly send out to employees, is very little. And so I thought, you know, if it would give us a greater sense of presence or, you know, connection, it’s worth that kind of investment, and so, that’s how we really approached it. You know, it’s gonna be easy, I think, as a skeptic, to say, “Look, we should be meeting in person, we should be, you know – we shouldn’t be escaping into a virtual world to escape reality.” And I think we’re not at all about escaping reality; it’s about adding additional modes of communication that can help when we aren’t able to be together in person.

     

    Interviewer:                So, what exactly are you doing in the Workroom? Are you spending all day long in it, or are you doing standups, or just ad hoc meetings? Or what is your kind of mode with the Workroom?

     

    Interviewee:                It’s sometimes standup, although not every day, and, you know, it’s generally ad hoc. So these headsets, right now, are wireless, the battery life is about an hour-and-a-half, so, you know, you don’t stay in there the entire day. We’ve reached a point where we’re comfortable being in there for an hour-and-a-half, if we want to be. But, you know, just to relay an event from a couple weeks ago, I was working on a production issue with one of our engineers, and there were two of us sitting side by side in this room, one of our screens was projected largely on the board in front, and we were working through this issue. Another member of the team joined the room thinking, “Maybe I’ll contribute to solving this problem.” He actually wasn’t able to; he just, like, he didn’t have the context.

    But he just kept sitting there, and he was here looking at desk working, and just kind of absorbing this background information debugging this problem. And I thought, “That is an experience I haven’t had since, you know, I’ve sat in an open-floor plan office, in years.”

     

    Interviewer:                So, I imagine your employees also, when you guys first started doing this, they were also a little skeptical of it? Or were they just really gung-ho to give it a try?

     

    Interviewee:                Mostly skeptical, I would say. You know, the first two – you know, I said we did three headsets, originally. We picked two people that were interested and engaged, but most people were skeptical. And again, I was, too. It’s just a low-cost investment. I suggest try it. And it won’t be for everybody, I think.

     

    Interviewer:                And have you had more people in your organization say, you know, “Count me in. This is the way I wanna work from now on”?

     

    Interviewee:                I think it’s gradually that way. I think, right now, the technology is – it’s pretty polished, but there’s definitely rough edges. I think the next-generation devices resolution is gonna be significantly better, you know, _____ _____ _____ battery life will increase. This very much feels like the early PC era, and being a business that’s adopting a technology that ultimately will be pretty ubiquitous, I think. And so, it’s really an organization question: do you wanna be on the leading edge of this or do you wanna be behind? I think, you know, I run an enterprise B2B software company, and we work on developer tools, and we work with developers all the time. We’ve actually had customer engineers voluntarily join us in our room, to work with us on an implementation issue, but then they’ll come back and just hang out later.

    So, I mean, there’s this mode of connection, even with customers outside the company, that I think is really compelling. Especially, you know, small companies, we’re always looking for any advantage we have [laughter], ’cause we have plenty of disadvantages. And this is one, I think, that we can really.

     

    Interviewer:                Well, that’s great, that’s great. So, why don’t we go ahead and jump into the Workroom, and we can check it out and you can kind of give me the grand tour, as it were. Sound good?

     

    Interviewee:                [Crosstalk] See you there.

     

    Interviewer:                All right, great, great.

    Well, this is an amazing environment, here. I love the fact that you guys are all able to get together. So, where is everybody located, in real-life?

     

    Interviewee:                I’m in Chico, California.

     

    Interviewee:                I’m in Portland, Oregon.

     

    Interviewee:                Austin, Texas.

     

    Interviewee:                Southwest Missouri.

     

    Interviewee:                Sacramento, California.

     

    Interviewer:                Okay, all right, great. So have you guys ever met each other in real-life?

     

    Interviewee:                A few of us, yeah, like, we used to – some of us worked together, previously. And then, we’ve had an opportunity to go up to Seattle and meet folks up there.

     

    Interviewer:                Okay, great. So, how do you guys like working in this virtual environment? I mean, do you notice any limitations to it, or do you find it pretty easy to use?

     

    Interviewee:                Mm, that’s a big question. [Laughter]

     

    Interviewee:                I thin both of those are true.

     

    Interviewee:                They are, yeah.

     

    Interviewee:                It’s really nice to be able to get together and work collaboratively on something in what feels like a physical space, but this is, and Jonathan talks about, this is a Generation One technology of this. And, like, you can see some people’s keyboards, like, I can see Jonathan’s keyboard over here, but you can’t see mine, because my keyboard’s not supported, yet. So I have to have this pass-through mode, so it looks like a ghost version of my desk right in front of me.

     

    Interviewee:                Yeah, text input for me is still a little – I’m kind of – I guess I have high expectations and I’m a little picky [laughter] about, you know, the typing and then being able to see it. And, you know, I recently had to get contacts, so, the Quest 2 headset uses your distance vision as, you know, like, of your prescription, so I have bifocals, normally. So, you know, your options are, like, third-party _____ that go on your lenses, or I went the contacts route, so that I could see [laughs], so that I could actually see things inside. So, that’s, yeah, that’s something to be concerned about.

     

    Interviewer:                Interesting. From a collaboration standpoint, though, are you guys finding it easier to be able to see, like, the same thing all at once and actually manipulate it or make edits to it? It seems like more real-time than real-time.

     

    Interviewee:                It did remind me a little bit of going to the WeWork [crosstalk] company we had at WeWork, and, you know, just being able to kind of hop in and out while other people are kind of doing their thing. And, you know, you’re sitting here and you’re actually talking, and it’s more real-life than Zoom, because it’s three-dimensional, you know, and there’s spatial awareness that, you know, you’re turning your head and things that you’re not doing on Zoom. So, Zoom, it’s very artificial, you know, it’s very 2D. So, those parts of collaboration, in my mind, are, like, the main benefit to it. The, you know, the various, like, logistical things, I think, like, Jonathan’s right, it’s, like, it needs to mature, significantly, before it will be not an annoyance, you know, to your normal workday, right? Like, you don’t want anything slowing you down; you only want to get the good value out of things, and it’s gonna take some maturation for that to happen, in the technology itself.

     

    Interviewee:                So, one of my favorite things about this is, you can see me holding the controller, here, and then, it doesn’t show you my other hand, but this bottom part, here – so this becomes a marker, as you get close. And so you just, like, writing, like, in this format, so. And I’m not writing on any physical surface, but it really feels like I am.

     

    Interviewer:                Huh –

     

    Interviewee:                Yeah, the controller gives you haptic feedback, when you get close to the whiteboard. You also can do the whiteboard on your local desk, and if you have your desk height set correctly, then you get the physical sensation of touching the controller to your desk, which is also another way to draw on there. You know, fine details and things like that, I think, are easier to communicate using that rather than just relying on [crosstalk].

     

    Interviewee:                Oh, [crosstalk].

     

    Interviewee:                Hello. [Laughter]

     

    Interviewer:                Okay. You guys, like, blend into each other, here.

     

    Interviewee:                Apparently, I picked the same location [crosstalk]. There we go.

     

    Interviewee:                And, you know, interestingly, I feel like personal space is still a thing, even in VR. You wouldn’t think that it would be, but, you know, if somebody, like, appears next to you in the table, it’s sort of like, “Oh, wait a minute, you’re kind of closer than you would be in real-life.” [Laugher] You know, you’re, like, in real-life, we’d never be sitting this close to each other, right, unless we were, like, directly communicating over a shared topic.

     

    Interviewee:                And it’s weird when they go to reach for something in their area, but, you know, it’s actually your area in the virtual space.

     

    Interviewee:                Yeah, you go to set down your controllers and you’re, like, putting your hands through your neighbor [laughter] [crosstalk].

     

    Interviewer:                This is awesome. So, are you guys, I don’t know, would you consider yourselves sold on this technology? Is it something that you guys wanna continue doing and utilizing, especially as it becomes more advanced and maybe user-friendly?

     

    Interviewee:                Hundred percent.

     

    Interviewee:                Yeah, I’m not sure that “sold” is, like, there’s nothing to sell. It is the future, right, like, it’s coming. Even if you don’t like it, like, this is the future of how we’re gonna do remote work. I’m just pretty convinced that that’s the case. I don’t see, you know, any other trend or anything in remote work that’s going to, like, overtake. This is going to just continue to get better, and, you know, the graphics and resolution, the frame rate’s gonna get better, you know, mixed reality rather than complete virtual reality, all of these things are gonna contribute to just a better remote work experience, I think, all the way around.

     

    Interviewer:                Well, that’s cool. Yeah, well, I would say that just this short introduction has really kind of shown me the capabilities and how it really can – I mean, I think this would’ve been awesome, well, even more awesome, if we had this two years ago at the beginning of the pandemic, when everybody was trying to, you know, figure out how they’re gonna work remotely fulltime. This would’ve been the way, you know, and then we wouldn’t be having these conversations about whether people should go back into the office or work fully remote or hybrid. I think that this would just be the way, moving forward, and everybody would recognize that. I think if I had one complaint about it, it’s the fact that these headsets are heavy. [Multiple “yeah” remarks] But, so, you know, I think as the technology improves, we’re gonna see a lot more companies adopt this.

     

    Interviewee:                Mm-hmm, totally agree, yeah. I mean, all of the mobile technology that has been building in all of the, you know, like, Apple devices, just consider the amount of complexity that’s in a handheld iPhone. And, you know, that’s all gonna be going into the headsets, you know, that high-resolution retina screens, you know, the game development algorithms, and the, you know, unity and all of the libraries that go with it, like, all of this stuff is – it’s not disconnected. It’s, like, totally, you know, the ecosystem that is sort of coalescing around this idea of augmented reality but virtual reality, right, totally made up reality that’s augmented by, you know, our presence. So, in that sense, it’s [crosstalk].

     

    Interviewer:                Yeah, it’s an immersive reality [crosstalk], yeah, awesome.

     

    Interviewee:                Yes, that’s a good way to look at it.

     

    Interviewer:                Well, guys, thank you very much for walking me through. This has been fascinating, and I gotta tell you that I am – I was a bit skeptical, but not anymore. I think that this is a great technology and you guys are doing great stuff with it, so, thanks again for showing me. I do appreciate it. All right, thank you, Jonathan.

     

    [End of Audio]

  • Why is Security Still in the Way? A Look at DevSecOps Right Now

    Why is Security Still in the Way? A Look at DevSecOps Right Now

    According to industry trend reports for 2022, DevSecOps is now considered to be one of the most effective approaches to building software quickly and securely. This effort, of course, means development, security and operations teams commit to addressing security as early as possible in the software development life cycle (SDLC). The goal of the shift into DevSecOps revolves around the need for more automation, streamlined CI/CD pipelines, less friction among teams and plenty of time for productive innovation. Incorporating DevSecOps practices into an organization unites security, compliance and development issues into a collaborative concern, one that allows DevOps to move fast without jeopardizing code quality. 

    As we approach the middle of 2022, it’s worth looking back and considering why security is still standing in the way of smooth software development. Security vulnerabilities have always been present in the process, and yet these pesky bugs continue to be the biggest threat to software performance. The question is, why?

    The Truth About Security

    Software has always been deployed and shipped with some existing bugs. But as software and services continue to dominate our everyday lives, the reality of this statement continues to plague both businesses and the end user. On some level, software development has yet to evolve into the next phase of security. Code is still rolled out regularly, only to discover security vulnerabilities in production. Some say the way software is developed today actually lends itself to defects, mostly because the pace of work required supersedes best practices around AppSec. 

    While the larger cybersecurity industry—and every DevSecOps team in the world—is striving to make software more secure, many organizations still prioritize speed and productivity over digital risk. This means the state of security (and, to some extent, the DevSecOps world) has become somewhat lopsided, with some enterprises making great efforts while others embrace a more lackadaisical approach. To make matters worse, many professionals today believe there has been a general under-investment in cybersecurity over the past several decades. 

    The Next Phase of DevSecOps

    The shift to remote and hybrid work models has led to mass adoption of cloud technologies and digital transformation, across all sectors and industries. As a result of this evolution, organizations today need to bear in mind that the more services they use, the more digital threats and overall risk they face. As this exposure to vulnerabilities increases, so does the need for new approaches to security. 

    The majority of modern enterprises do, in fact, have a security process in place, as well as other risk management solutions. But with the cybersecurity reckoning of 2021 and the stakes of cloud computing being higher than ever, businesses right now are feeling the pressure to think long and hard about why security still isn’t a guarantee. The trend of slowing down software development to address security more thoroughly, also known as the secret sauce of DevSecOps, is not free from roadblocks—but it is also far from optional. For many organizations, the implementation of DevSecOps practices feels less like security and more like speed bumps that just slow down the shipping of software. 

    Even so, the effort to improve security is happening now. Organizations do not need several solution platforms or tools to get started. They can begin right away; evolving their security tools and practices as they grow the business. With this growth comes one of security’s biggest challenges—scalability. Because toolchains across the cloud have become more and more complicated, setting policies and/or workflows in one tool is challenging. While these issues can be largely addressed by the adoption of an end-to-end security solution, organizations must continue to focus on strengthening supply chains, improving security oversight, and bolstering their approach to DevSecOps. Some ways to make this happen include:

    • Making sure CI/CD pipelines are integrated with DAST and SAST testing in development
    • Ensuring developers and DevOps teams complete vulnerability scanning before commit or merge, as they write code
    • Minimize manual security as much as possible with automated AI/ML tools to support more effective scanning and monitoring
    • Invest in management solutions that improve security in a multi-cloud environment

    Addressing the Supply Chain

    According to an industry survey, 60% of companies have decided securing the software supply chain should be a top priority for 2022. When we think about software supply chain attacks, we need to think about better controls to validate its integrity through all stages of the SDLC. Obviously, DevOps and automation have provided considerable help in this area; however, they cannot pull all the weight of security without proper governance and guardrails. 

    With a secure supply chain comes better security, as well as compliance, privacy and transparency. When a supply chain is secure, it can automatically enforce policy requirements for things like instrumentation, testing and architecture. As a result, software development and deployment become a repeatable process that is also reliable. Teams across the organization can rest assured that the products and services they are building comply with security expectations, such as validating code before production with static analysis and scanning tools. 

  • When DevOps-as-a-Service (DaaS) Meets Security

    When DevOps-as-a-Service (DaaS) Meets Security

    One of the most recent IT methodologies to be offered as a service is DevOps, a cultural and practical approach that brings development and operations teams together under one umbrella of work. DevOps-as-a-Service (DaaS) ensures that everything related to the selection, management and maintenance of DevOps tools and infrastructure, including all policies and procedures, are addressed through a centralized team who are able to provide this service to development teams across the organization. 

    From a 30,000-foot view, DaaS represents DevOps capabilities made accessible to practitioners through portals and APIs. Because DevOps capabilities vary among organizations, there is no standardization of these services. For the business, DaaS enhances competition. Application users and developers find DaaS improves overall software development, while specialized DaaS teams say it improves the management of DevOps capabilities.

    What Are the Other Benefits of DaaS?

    DaaS offers many benefits, especially to development teams who no longer want to spend all their time configuring and deploying the necessary security tools to run DevOps pipelines. This means it’s no longer necessary to understand all the differences between DevOps tools and the underlying infrastructure, as the appropriate tools and technologies are automatically deployed for development teams. As a result, developers are able to focus their efforts on creating innovative software at the speed of business. 

    Further, Daas delivers clear business and operational benefits in the form of a more streamlined process for facilitating DevOps across the enterprise. Daas supports governance while also enabling centralized oversight and visibility into development workloads and productivity. As we know, this shift leads to increased accountability among teams and an overall optimization of business processes. Add on resource efficiency and cost savings through tool selection, and it’s easy to see why DaaS has found a home in the world of software development. 

    But despite the benefits, Daas also presents new security challenges that can’t be fully addressed by traditional management solutions. These approaches are often sluggish, expensive, and/or incredibly complex to manage.

    What About Security and DevSecOps?

    Because the principles of DevSecOps proactively address the risks and threats associated with DevOps processes, it has seen rapid adoption in recent years. By integrating AppSec tools and strategies within a DevOps pipeline, developers are able to find and fix security vulnerabilities earlier within the software life cycle—not after the fact. This ability is what allows developers to generate secure and high quality software from the beginning, while also preventing any deployment delays stemming from last-minute security checks in production. With DevSecOps processes in place, AppSec testing becomes seamless and transparent for developers, who need a frictionless experience to facilitate steady and reliable software development and deployment. 

    DevSecOps is a  natural fit for the as-a-service delivery model. Similar to DevOps, AppSec involves various tools, policies and processes that demand a certain degree of professional expertise—not to mention the time and resources it takes to to select, maintain, and deploy them to drive DevSecOps practices. Security and development teams looking to  implement and manage DevSecOps can reap major benefits from a centrally defined and managed process, to be administered by a specialist team and delivered “as a service” to those in charge of DaaS.

    Standardizing AppSec through a DevSecOps-as-a-Service offering would guarantee security is applied evenly across all DevOps activity, thereby allowing businesses to produce secure and high-quality software consistently while also supporting AppSec compliance demands. This shift also establishes a foundation where a holistic and homogenous view of AppSec can be found, one that is critical to the assessment and management of application and business risk. 

    Developing DaaS Metrics

    First, don’t try to boil the ocean by measuring all applications at the same time. Instead, choose an application that’s supported by DaaS processes and appoint a specialized team to develop metrics for the application. This team can look many ways—but would likely include stakeholders, developers and other DaaS-supporting roles. Service-level indicators (SLIs) and service-level objectives (SLOs) are also baked into this model, which are chosen to best suit the requirements of an individual application. 

    Once the most valued SLOs of DaaS are determined, the service can be tailored to identify the most critical SLIs. With this knowledge, things like instrumentation, telemetry and analysis requirements can be identified and used to design alerts, dashboards, analyzers and more. Next, setting up policies and procedures around accountability establishes a complete solution. And once the solution for the chosen application is tested, confidence kicks in and creates an easier process for adapting and expanding the process around other applications. 

    This means DaaS can provide many key capabilities to both the organization and the teams who rely on them. A specialized DaaS team can then figure out the best metrics for larger implementation on any application. As a result, SLOs can be evolved for other future applications, to be used as a baseline for future improvements. 

     

  • Agile Development at 20: Can it Thrive in the Hybrid Work Era?

    Agile Development at 20: Can it Thrive in the Hybrid Work Era?

    The Agile Manifesto turns 20 this year, and while many of the core tenets are still applicable, the world has changed considerably in the last two decades. What would the Agile Manifesto look like if it was written today and took into consideration our new reality of hybrid working environments? Changes are most definitely needed, as software leaders still find themselves struggling to navigate the murky waters of 21st-century project management to get the most out of their team.

    Developers have many complaints about Agile, but most of them boil down to the fact that they often spend more time planning for work than doing it. For example, developers sometimes feel that frameworks like Scrum are top-heavy and bureaucratic, which is the opposite of their intended purpose. Developers can also feel disconnected from the bigger goals of their project, being trapped in an endless list of “to-dos” without the time to think holistically about the features they’re creating.

    With these concerns in mind, let’s take a quick look at what the original Agile Manifesto actually included. It started with four primary values:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change by following a plan

    On their faces, all of these seem reasonable; even approaching plain ol’ common sense. But in their zeal to focus on code development rather than bureaucracy, the authors couldn’t have anticipated how much the industry would change. Consider some of the trends we’re seeing in today’s software development teams.

    First and foremost, the idea that “every company will be a software company” has become a reality. It’s hard to imagine an industry that doesn’t leverage software in some way to address its core competency. This trend has, in turn, fueled another major trend: The war for developer talent. Skilled developers were already at a premium prior to the Great Resignation in the wake of the pandemic. Now, developers hold substantial leverage over their employers in ways never seen before.

    The Pandemic and the New Normal of Hybrid Teams

    The pandemic has also brought us the new normal of remote, distributed teams and asynchronous work styles and skilled workers are spread across the globe. There are also new technologies that enable more automation for software teams, including machine learning and AI and other methodologies (like DevOps and DevSecOps) that reduce workloads for developer teams by using automation and process-driven workflows.

    These trends have given rise to particular needs for almost all hybrid developer teams. They include significantly improved productivity for faster software delivery and developer-friendly tool experiences that speak directly to how developers work today. Teams also require guided, asynchronous processes that map to the reality of highly distributed teams. Finally, as the cloud era is firmly a reality, developers need new technologies that offer the ability to scale predictably without suffering from increased complexity.

    Now, let’s look at the original Agile values through the lens of today’s trends and needs. The first is valuing individuals and interactions over processes and tools—this definitely requires an update for today’s developer teams. Specifically, process is a prerequisite for productivity. It is an enormous challenge to measure productivity or determine if the team is improving without a consistent process to follow. Without agreed-upon rules for working together, software development can quickly devolve into chaos. Second, putting individuals and interactions over tools seems like a restrictive viewpoint today. Good tools are explicitly designed to facilitate productive interactions between individuals. If they don’t accomplish this goal, they are poor tools; but there are many solid reasons that great tools can increase productivity and make developer teams’ lives much more manageable.

    The second value of the Manifesto also seems to present a false choice, as it prioritizes working software over comprehensive documentation. Its heart is in the right place—who wouldn’t want to focus on building workable code rather than creating documentation? However, in the world of distributed teams, detailed documentation is critical for both remote and hybrid teams. This also encompasses documentation that goes beyond just the codebase. Documentation involving decisions, requirements, process, etc. also provides context for teams that are adjacent to developer teams and help them understand progress and goals. Documentation is also helpful for addressing the skills gap and talent shortage. New hires or newly-promoted team members need to get up to speed quickly and provide value as quickly as possible. In addition to training, good documentation can help them do that and help their teams be more productive more quickly.

    The third value of the Agile Manifesto said that we should focus on customer collaboration rather than contract negotiation. I believe this needs a slight but essential adjustment for today’s hybrid teams. Specifically, teams should be building with end-users,—not just “customers”—in mind, which means that the needs of whoever will be using the end application regularly should be paramount. This is particularly important today given how many end users are involved in buying decisions.

    I think the final value of the Agile Manifesto—responding to change over following a plan—needs no edits whatsoever. This remains great guidance for developer teams everywhere, and it seems the Manifesto should take this advice and adapt to the many changes that have occurred since it was first written.

    Many of the 12 principles of the Agile Manifesto continue to be outstanding guidance that is applicable for most developer teams. There is, however, some nuance that should be considered for a couple of them. To wit:

    “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”—This is true, but today, remote and hybrid teams are a reality. That’s not changing any time soon. Teams need to optimize for asynchronous communication and collaboration.

    “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”—Sure, but given the myriad demands on software teams, developer burnout needs to be monitored and managed or overall quality and productivity will suffer.

    “Simplicity—the art of maximizing the amount of work not done is essential.”—I couldn’t agree more, but in my mind, this means that teams should leverage automation where possible to maximize “work not done.”

    Conclusions

    In general, it seems that the Agile Manifesto holds up pretty well, provided that today’s workplace realities are taken into account. If software teams recognize that tools and processes create conditions for greater productivity and that documentation is critical in a remote/hybrid world, their remote Agile teams will be much better off. In addition, teams should build with end-users in mind, not just customers. With this added nuance and recognition of a changing world, today’s software teams can continue to thrive while leveraging this decades-old advice.

  • Secure Software Summit Series: Focus on Preventative Readiness

    Secure Software Summit Series: Focus on Preventative Readiness

    The connected world economy and the COVID-19 pandemic forced companies to accelerate digital transformation. Sophisticated cybercriminals have seized this forced acceleration to lay the groundwork for cyberwarfare. In reaction to recent attacks ranging from the SolarWinds breach to the recent Log4Shell exploits, many companies have quickly isolated and patched their systems. However, these reactive fixes do not work all the time; nor does the watch-and-wait approach. We must focus on re-engineering our organizational operations and culture to build and maintain preventative readiness. Companies and infrastructures need to be more resilient and secure from the start by building secure coding practices into the development process.

    Secure Software Summit

    At the beginning of 2022, ShiftLeft hosted the Secure Software Summit to provide industry experts and practitioners in the software development world a platform to discuss the latest methods and breakthroughs in secure coding and development practices—securing code earlier and better has become a discipline unto itself!

    Some of the main takeaways from the event were:

    SBOMs are in Your Future

    In the very near future, organizations will need to better account for all the software and components of their applications, most likely via a software bill of materials (SBOM). The U.S. government has mandated barebones SBOMs, and we will soon see private industry start to mandate them, too, as part of procurement processes and auditing. This will enforce greater transparency and automate discovery of all dependencies and components in a way that, until now, was not common. Software composition analysis (SCA) will make this process easier and will become a standard part of the build process and the application development life cycle.

    Securing Open Source is Critical

    With Log4Shell and other open source software (OSS) supply chain attacks, application security teams must learn how to more intelligently update and secure the most critical OSS components and infrastructure. The average AppSec team needs to sift through massive piles of vulnerabilities and suggested security fixes — far more than they can possibly fix. We have seen record numbers of new vulnerability disclosures in each of the past four years. Proper prioritization based on whether a vulnerability can significantly impact an organization’s own applications and infrastructure is now essential amidst the blizzard of OSS dependencies that make up the modern application.

    Digital Threats Impact the Real World

    For many organizations in non-tech verticals such as health care that consume a lot of software, application security is at a crisis point—software vulnerabilities can literally put lives and our economy at risk. Researchers have correlated increases in mortality with hospitals running at higher levels of stress and capacity. When ransomware or other attacks impact health care institutions, the effect is the same as a massive pandemic flooding the ER: Doctors can’t use systems or equipment, care is rationed, patients are turned away and everything becomes more time-consuming. The net result is more deaths. Securing these systems against attacks becomes a matter of life or death—literally.

    Culture Change Must Come First

    Organizations will deploy new security architectures such as zero-trust, but these attempts will only be successful if AppSec and development teams change the culture around security. Organizations must recognize that the new normal is a state of constant renewal of trust. This will be challenging; constant renewal of trust requires entirely new infrastructure and a new mindset that can be hard on humans. It means implementing multifactor authentication in many more places and removing conveniences like administrative accounts that have blanket access to systems; it requires implementing least privilege practices. Software development will need to bake this constant renewal of trust into workflows and tooling to make it the new normal.

    Shift From Reactive to Proactive

    AppSec and development teams must shift from reactive approaches that tend to mobilize most resources during a breach or an incident and emphasize more proactive approaches such as better software security analysis and security chaos engineering. Knowing the unknown unknowns before they become a problem is key here. Netflix, which pioneered chaos engineering, recognized that stressing systems frequently and constantly to see how they behave under adverse conditions often yielded surprising insights that could improve security (and resilience, more broadly). As mentioned above, creating better ways to prioritize vulnerabilities and focus on the ones that are actually attackable shifts the task from a hopeless burndown to a targeted and proactive tactical exercise that is manageable. 


    Stay tuned for more articles to follow written by the following keynote speakers from the event:

    • Aaron Rinehart, Verica – Security Chaos Engineering
    • Dan Lorenc, Chainguard – The State of OSS Supply Chain Security
    • Steve Springett, OWASP – Behold the SBOM
    • Shinesa Cambric, Microsoft – Importance of Securing Software with a Zero Trust Mindset
    • Malcolm Harkins (Epiphany Systems), Rob Lundy (ShiftLeft) and Bryan Smith (RiskLens) – Reachability and Attackability
    • Abhishek Arya, Google – Measuring and Mitigating Risks in Open Source Software
  • How AI Can Improve Software Development

    How AI Can Improve Software Development

    Change is constant and inevitable. While some changes are welcome, others are just a necessary evil. 

    Continuous calls for digitalization combined with a pandemic-prompted emphasis on transforming business operations, force organizations across industries to modernize their legacy systems. The emergence of cloud computing has shrunk organizations’ on-premise IT footprints. However, with 96 of the world’s largest 100 banks, 90% of the world’s largest insurance companies, 23 of the 25 largest retailers in the U.S. and 71% of the Fortune 500 still using mainframe systems, any modernization efforts—resulting in increased risk of downtime or defects—will frequently lead to disastrous consequences. 

    So, while making changes can be expensive, uncertain, and lead to customer loss and/or embarrassment in the marketplace, modern business demands that systems change to continue to deliver value. The problem with mainframe modernization, however, is that today’s code search tools, linters and program analysis tools are deficient when it comes to mitigating the risks associated with maintaining and improving systems. 

    Modernization: A Knowledge Problem

    With 10,000 mainframes in active use globally, the average organization annually spends anywhere from 60% to 80% of its IT budget just on maintenance. But, as experienced and proficient programmers retire or move on, many companies are realizing that the specialized domain knowledge of the industry and institution that those developers used to create and update these complex critical systems is walking out the door with them. 

    As the developers who originally wrote the code have long since moved on, and documentation leaves a lot to be desired, developers new to a system are unable to acquire comprehensive knowledge of the system’s functionality, at a detailed or fast enough level, to become adequately productive and proficient. That lack of speed comes with significant risk and cost to any organization.

    Recognizing the full and true intent of the functionality written in code is not simple. Developers today spend roughly 75% of their time searching through source code, to identify the code representing the functionality that needs to be changed. Complicating matters further, understanding the code is not enough. To effectively and efficiently maintain and support any system, software developers must know precisely what an application actually does—and how altering code in one part of the system impacts it as a whole. But since the code representing a behavior that needs to be changed can be littered throughout the system, developers might think they’re making a simple tweak, when really they may be breaking the entire system (and not even knowing it). The risk of change resulting in unintended consequences is real.

    All of that being said, how can developers improve their efficiency and effectiveness?

    The Shortcomings of Today’s Tools

    With code repositories growing unchecked over time to extraordinary sizes, those responsible for maintaining and preserving a system’s functionality say it’s becoming increasingly challenging to find bugs in code without machine assistance. And with debugging being an arduous, time-intensive endeavor, developers are increasingly turning to code search tools, linters, and static and dynamic analysis tools to analyze millions of lines of code, flag errors and suggest fixes. 

    Whether the tool excels at bug localization, code visualization or “error” detection, entirely too many tools are insufficient when it comes to actually identify the specific lines of code that require attention. Program analysis tools only illustrate code in ways that developers still have to interpret (potentially incorrectly) and draw their own conclusions. While code search tools might speed the rate at which developers can build a mental model of the code, such tools are notorious for false positives, and developers still have to undergo the mentally challenging endeavor of piecing that mental model together to identify the code, and then safely make changes. Worse yet, code completion tools—tools that less-experienced developers disproportionately rely on—can actually propose imprecise changes (one prominent tool offers incorrect code 71% of the time), and that introduces risk.

    The cherry on top of this problematic sundae is that today’s tools don’t have any way to effectively validate the scope and accuracy of a proposed change. The influence of a suggested change can be tough to identify, so testing for comprehensive validation is frequently next to impossible. 

    Ideally, there has to be a better way to mitigate risk while making changes to legacy systems. Enter artificial intelligence. By employing a unique approach to AI, the code repository truly becomes a knowledge repository, enabling many capabilities unrealized before now. 

    A Developer’s AI-Enabled Accessible Knowledge Repository 

    By leveraging AI to automate the identification of the specific lines of code that require attention, developers can simply ask this AI-driven knowledge repository where behaviors are coming from—and quickly identify the code associated with that behavior. This puts AI squarely in the position of intelligence augmentation, which is key to leveraging its capabilities. 

    This novel approach of AI reinterprets what the computation represents and converts it into concepts, therefore “thinking” about the code in the same way humans do. The result is that software developers no longer have to unearth the intent of previous developers encoded in the software to find potential bugs. Even better, developers are able to overcome the inadequacies of automated testing by using AI to validate that they haven’t broken the system before they compile or check in the code. The AI will forward simulate the change and determine whether it’s isolated to the behavior under change. The result is the bounds of the change are confined to the behavior under change so that no unintended consequences arise.

    While AI is not yet advanced enough to safely make changes on its own, it can serve as a knowledge repository with the added capability of directing developers precisely where to make any needed changes. With AI, programmers—even on their very first day on the job — can make any necessary fixes with confidence that they won’t break the entire system. 

    Unlike its code search, code navigation, code completion and program analysis tool counterparts, AI fundamentally empowers developers to safely, efficiently and effectively make any necessary changes. With AI — that is fortified by a knowledge repository that understands source code the same way a human does — developers can truly do more with less. 

  • Best of 2021 – How to Combine DevOps and Agile

    Best of 2021 – How to Combine DevOps and Agile

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the thirteenth in our series of the Best of 2021.

    In recent years, application development and deployment have become an increasingly critical part of business operations. Because of this, various entities have sought to optimize their product development process.

    This has led to a rise in the popularity of DevOps, which is designed for that purpose. In simple words, the DevOps application during the software development process reduces the number of steps necessary to bring software to market. These faster releases and streamlined processes mean swift user feedback.

    DevOps implementation focuses also on the software scalability, how well it could be deployed and also its monitoring and maintenance after the future releases However, there is also a downside to traditional DevOps benefits. The system does not include the kind of continuous testing and improvement that Agile offers. 

    This has led to Agile practices being overwhelmingly focused on what you might define as the development aspects of software delivery. Though, there is less focus on operational aspects.

    Hence, both practices are quite critical to be implemented in the SDLC of any product. 

    Separating Agile and DevOps approaches to software development leads to the building of the product but its deployment, work automation, as well as infrastructure management fail as it’s “somebody else’s problem” when the Agile team is looking at it. Moreover, “operability” disappears into the background.

    The solution is combining Agile sprints with the integrated teamwork offered by DevOps. By doing so, you can optimize incrementally the development lifecycle and maintenance of your product both. It helps to correct an imbalance but has little influence over the practices that happen during the continuous development phase.

    What is Accomplished by DevOps and Agile Integration?

    The integration of DevOps and Agile helps in the following areas:

    • Streamlines the release process and improves product offerings.
    • Allows for better collaboration.
    • More value and fewer risks in each release. 
    • Fewer bugs and faster fixes.
    • Increased visibility.
    • Higher user satisfaction rates as the products are more qualitative.

    What to Pay Attention to When Integrating DevOps and Agile

    To simplify the process of implementing DevOps into Agile product development we have gathered the most common pitfalls that might happen during this process and how to avoid them making your process working smoothly.

    Improve Teamwork Flow

    Using the DevOps framework and Agile approach together makes it crucial that team members have a broader understanding of all development aspects. You get DevOps business value and the practicality of Agile together. 

    Team members such as the Product Owner, Scrum Master and the PM, along with operations, infrastructure and sysadmin roles need to consider not only the software development process but also delivery and maintenance. Your teams should be equipped with the knowledge of release, service and change management, environment provisioning, automation and tools, and application deployment. Build-and-run product-centric teams solve the problem of the Agile development-to-operations hand-off.

    Defining the Lifecycle

    Successfully attempting a DevOps implementation plan with an Agile framework means defining the product lifecycle. This increases consistency, reduces cost by minimizing waste and speeds up a time to market. Teams now inherit more of the operational concern within the entire lifecycle. Therefore, it’s ideal if you start to implement some of the DevOps principles right at the beginning of your development process. 

    DevOps Adoption in Sprints

    Agile workflow assumes the software development process divided into sprints, therefore it’s strategic to integrate DevOps management while handling sprints.

    Follow these instructions as you start working the DevOps approach into your Sprints.

    • Invite ops/infrastructure/support personnel to planning sessions.
    • Discuss product functionality and operability features.
    • Include them in the upcoming sprint.
    • Involve the DevOps team in sprint backlog planning and daily meeting, as well as sprint review and scrum and plan alignment.

    The engagement and collaboration of your development team and operations team also keeps the ops team abreast of functionality release timelines. The ops team can then help the dev team in planning the release schedule with greater accuracy and can assist the dev team in shipping the product faster.

    Including QA in Each Phase

    Making the QA part of the entire development lifecycle is another essential factor when integrating DevOps and Agile. Testing assumes a vital position when combining the two. Besides functional testing applied in Agile, DevOps approach requires performance and load testing of the software. Hence, constant testing is equally as important as continuous development.

    Implement Service Backlog Under DevOps

    When implementing DevOps and Agile together, you need to rebuild your service backlogging process. As under DevOps framework, it should include: 

    • Scalability of the software.
    • Deployment capability.
    • Service monitoring.
    • Logging.
    • Setting alerting. 
    • Software testing. 
    • Security and compliance aspects.
    • Operational performance.

    Leveraging the Right Tools

    Using the right tools is the key to successful Agile and DevOps adoption into your software development. Keep in mind that applies to your software development process configuration management tools to create and replicate infrastructure using the Infrastructure as a Code (IaaC) concept needed for DevOps. This helps developers to deploy the application on different types of platforms without any reworking efforts.

    Automation

    Automation of workflow is another part of Agile combining with DevOps. Try to automate all the code scanning processes and avoid any potential vulnerabilities. Build artifacts in a repository, or automate the release out the door. Automate these elements entirely so your end-to-end goalposts are the one possible places where someone has to manually check for issues.

    Documentation 

    While in the Agile approach, teams don’t document their meeting minutes or other communications. Instead, they prefer lo-fi methods such as pen and paper. DevOps, on the other hand, requires entire design documentation and specs to understand a software release.

    Measurement and Analysis

    Well, after building DevOps into Agile project management to keep track of its progress, you need to care about establishing the metrics to measure its effectiveness. This allows for the successful enablement of multiple releases to production faster. As under the Scrum Alliance Organization recommendations, some of these could be:

    • Percentage of release date adherences.
    • Percentage increase in release numbers.
    • Time taken for release to production.
    • Defects attributable to platform/support requirements.
    • Percentage of NFRs met.

    Though you can define other metrics during DevOps implementation to measure that have higher business value.

    Why DevOps and Agile both matter should be obvious now. Though these practices serve to streamline and simplify the product creation and deployment processes, combining Agile and DevOps requires a shift in the organizations. But putting efforts in combining Agile and DevOps management in the right way, you will see how it can improve your development process and deliver results in reliable, scalable and maintainable applications.

    — Slava Vaniukov