devopsy.kinsta.cloud

Tag: custom software development

Successful Software Development in a Hybrid Environment

The desire to work from home or from anywhere has only increased as the COVID-19 pandemic lingers. Employees cite a number of reasons why they prefer to skip the office, including cutting commuting times, being more productive, caring for family members and exploring new locations. People are increasingly comfortable with remote interactions and the new technology tools that have sprouted to support the work-from-anywhere trend. On average, employees said they want to work from home 2.5 days a week, according to a monthly survey of 5,000 Americans, while 73% of employees seek hybrid work environments where they have some flexibility in where and when they work.

The rapid spread of the COVID-19 Delta variant also prevented employers from enforcing a full-time return to the office. As a result, the new normal for today’s workforce will remain hybrid at best—a few days in the office and a few days working at home. We are a workforce in transition. For many companies, this has put an unnecessary strain on their digital transformation initiatives.

A question remains: How can companies continue to innovate and execute on their software development initiatives with their employees separated from their teams and offices? Here are some of my recommendations for helping organizations to continue their software development projects in today’s hybrid work environment:

Inclusive Environments

Hybrid workforces require a highly inclusive environment. As a nearshore IT partner that works with hundreds of clients remotely, we ensure that our teams have the same access to managers, HR and the technology necessary to succeed on projects and to productively engage with clients. For example, we have learned that the best way to be inclusive is to take either an all-virtual or all-in-person approach during client meetings. It’s also critical to train your managers to provide the same advancement opportunities to employees regardless of whether they are in or out of the office. From the executive team on down, everyone needs to support employees, regardless of where they are. The same goes for onboarding new employees and partners—a mostly virtual process over the past 18 months. Increasing online mentoring and onboarding platforms to connect employees and to manage client projects while the workforce is hybrid is another significant approach we have taken to ensure everyone feels included and engaged.

Collaboration and Knowledge-Sharing

Employees were abruptly forced to transition away from the office where they were used to frequent impromptu meetings and lunchroom chats. For many, this shift had a negative impact on brainstorming, collaboration and knowledge-sharing and thus, innovation. We give our teams the flexibility to use different technology tools to make up for what they miss most in an office environment—regular, casual human interactions. Our teams use a variety of communications tools for frequent check-ins to connect with clients and their co-workers. As a result, our people say they are more engaged with team members and clients than ever before. They are doing more impromptu chats and “instant” meetings with colleagues and clients as if they were in the office. We also migrated to video conferencing as our communication channel of choice. Video conferencing tools increase engagement and allow team members to join virtual meetings anywhere from their preferred devices. The ability for teams to interact, share and collaborate wherever they are is essential to developing cutting-edge teams and software.

Trusting Cultures

According to the Harvard Business Review, 34% of employees felt that their supervisors “expressed a lack of confidence in their work skills,” and an even more significant number of workers reported feeling that they needed to be constantly available to prove themselves. Sentiments like these highlight a lack of trust, impacting development outcomes. Employers need to trust that their employees are working diligently and consistently throughout the workday or whenever they can successfully complete the tasks at hand. For example, working remotely allows individuals to work when they feel most productive. Organizations need to recognize individual productivity cycles and understand that different team members may be productive during different times of the day, including outside of normal business hours.

Being transparent, forthcoming and open about expectations are keys to building trust with employees. Successful digital transformations and innovative software development are only possible with the right team and people. From a client’s perspective, these are the types of IT partners they want on their side. Technical aptitude and an environment where all employees feel valued, trusted and motivated to do their best are critical for developing effective digital solutions.

Employees have made it clear that they don’t want to be back in the office full time. For many organizations, a return to normalcy centers on developing a hybrid workforce that can work effectively with digital development partners. Creating the right environment and strengthening employee relationships are keys to ensuring software development projects can continue successfully in today’s new normal.

November 15, 2021
Google Makes Fuzz Testing Integration Tool Available

Google today made available a ClusterFuzzLite tool that makes it simpler to incorporate fuzz testing into a DevOps workflow.

Fuzz testing refers to an automated software testing technique that involves providing invalid, unexpected or random data as inputs to an application to discover issues such as potential memory leaks.

Jonathan Metzman, a senior software engineer for Google, said ClusterFuzzLite is a lighter-weight version of a tool that Google makes available to its internal development teams. It is not a fuzz testing tool itself, but rather a tool that makes it easier to surface the results of a fuzz test within a DevOps workflow. Once those results are surfaced, it then becomes easier for developers to address issues before an application is deployed in a production environment.

Core capabilities enabled by ClusterFuzzLite include continuous fuzzing, sanitizer support, corpus management and report generation tools. The goal is to make fuzz testing more accessible to a broader range of developers as part of an overall effort to embrace DevSecOps best practices, noted Metzman.

ClusterFuzzLite currently supports GitHub Actions and Google Cloud Build, but Metzman said it is easily extensible to other DevOps platforms. It is designed to run as part of a DevOps workflow by adding a few lines of code to a continuous integration/continuous delivery (CI/CD) workflow.

Google has already made ClusterFuzzLite available to open source projects, but is now providing additional access for commercial developers. Since its release in 2016, over 500 critical open source projects have integrated into the Google fuzz testing program for open source software, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed.

In the wake of recent guidelines issued by the U.S. National Institute of Standards and Technology (NIST) that were themselves in response to an executive order issued by president Biden, the number of organizations using fuzz testing is expected to increase now that NIST has determined that fuzz testing is a minimum standard requirement for code verification.

For several years, Google has been making a concerted effort to improve the security of open source software. The challenge for all developers is finding a way to build more secure applications without slowing down the rate at which they are deployed. Fuzz testing makes it possible to identify issues much earlier in the application development life cycle versus just before an application is deployed.

Less clear, of course, is whether developers are starting to use these tools on their own or if the increased adoption is because of a concerted effort by their organization to embrace DevSecOps best practices. Regardless of the motivation, however, the overall state of application security should continue to improve as it becomes simpler for developers to invoke more advanced testing tools.

In the meantime, organizations of all sizes are reviewing how they construct software in the wake of a series of high-profile security breaches. In theory, at least, increased focus on software supply chains should prevent issues from arising after deployment when they become much more costly to remediate.

November 11, 2021
Automated Refactoring with Moderne

Jonathan Schneider and Olga Kundzich are co-founders of Moderne, a Seattle-based startup. Moderne received $4.7 million in seed funding in July 2021 to commercialize OpenRewrite, an open source automated refactoring tool for code (initially Java) that Schneider started while at Netflix. Moderne’s technology reduces the tedium and time it takes for software remediation; a big problem in today’s world of cloud-native development. The video is below, followed by a transcript of the conversation.

Announcer: This is Digital Anarchist.

Alan Shimel: Hey, everyone. Welcome to another segment of TechStrong TV. We have a new company to detail for you, and we have two cofounders here to tell you all about it. It’s a great open source story as well. Let me introduce you to – and I’m gonna do my best not to mess it up – Olga Kundzich, Kundzich, Kundzich – three times the charm – and Jonathan Schneider. I think I got that one on the first try. Olga, Jonathan, welcome to TechStrong TV.

Olga Kundzich: Great to be here.

Jonathan Schneider: Thanks. It’s good to be here.

Alan Shimel: Thank you. So the only rules is only one of you can talk at a time, but both of you can talk as much as you’d like. But why don’t we start off with maybe a little bit about each of you. Olga, if you don’t mind, why don’t you go first and maybe share with the audience a little bit of your background and how you came to be here today.

Olga Kundzich: Great. So my background, I was working at Pivotal on a Spinnaker continuous delivery solution, and that’s where Jonathan and I had met. We worked together there for about a year and a half. Prior to that, I worked at EMC in engineering for, in different functions for a number of years. So when we were working together on Spinnaker, we talked to a lot of people in the industry. There was a lot of interest around that product, and kind of we realized that everyone had sort of the same problem. We would start a conversation about some old feature, and it will come back to, well, all my application is still stuck on this old, aging framework, and let me talk to you in a year when I migrate all of this back.

So and the problems were highly repeatable and kind of same framework, same third-party vulnerabilities, same libraries, APIs, so after reflecting on this we realized that this is really not a coincidence. It’s a consequence of modern application development practices. Our software right now is 90 percent third-party dependencies, open source, APIs, so the problem’s kind of highly repeatable. And that’s kind of led, what led us to, back to technology that Jonathan developed earlier at his time with Netflix and kind of take it, develop a lot of more functionality into that sort of large-scale distributive factoring that will help us solve these type of problems, the framework migrations, API migrations, CVE patching that cross all of these open-source and third-party dependencies.

And I will let Jonathan speak about his background and a little bit on the open-source framework.

Jonathan Schneider: Yeah, so Netflix had this engineering culture called freedom and responsibility, so product engineers were sort of, had the freedom to do whatever they wanted really. They could use their, a different build tool, they could use their particular Java style, they could use whatever libraries they wanted, and so forth. And so as a central team, if you’re on an engineering productivity team or you’re on a platform team and you’re trying to effect some change inside the organization, we couldn’t put up gates in front of product engineers that would, say, break their build if they didn’t comply with a certain thing. Instead, you tried to build tools that would help bring them along on a journey with you, and I kept hearing the same thing over and over again from engineers which is, hey, I got a lot on my plate. Happy to move forward to this new pattern that you want to see, if you do it for me. If you just do the work for me, I’m happy to commit it.

Alan Shimel: Nice of them.

Jonathan Schneider: And of course, you know, you think there’s two of us and 700 of them, and that doesn’t scale super well. Right? So that’s where we started working on a way of actually automating the source code transformation. When we developed that technology, one of the consequences of that freedom and responsibility is that there was not a consistent style of the code or consistent patterns, necessarily. So that refactorization we built had to make transformations that were, looked like they were a developer writing in that code base stylistically consistent, hundred percent accurate changes. And so we got some interesting results out of that, so when Olga and I were working together and you would hear, “Oh, I’m still stuck on Spring Boot 1 and I’m trying to get to Spring Boot 2,” or, “I’m stuck on JUnit 4. I’m trying to get to 5,” we just found another application of this at a larger level in a highly repeatable problem space.

Alan Shimel: Fair enough. You know what, I’ve spent the last 20 plus years talking to founders. I’ve founded my own companies. This is what happens. You see a real problem. Right? See a real-world problem. There’s got to be a better way we could solve it. Sometimes you find out solving that problem is not as easy as you thought. Sometimes it is, very rarely. But you work through it and that’s what startups are all about. In your case, though, I mean, look, Spinnaker, which is now part of CDF, right, was managed by CDF, but Google, Netflix were instrumental in the development of Spinnaker. But Spinnaker is an open source tool, and you guys went with an open source route in what you’ve developed. Why don’t we talk about that a little bit?

Jonathan Schneider: Sure, yeah. There’s really two parts to our product offering. There’s OpenRewrite, which is GitHub slash OpenRewrite. OpenRewrite is that core refactoring technology we’ve been talking about that can make stylistic automatic and consistent changes to a code base. On OpenRewrite we built recipes, so we have a recipe to migrate you from Spring Boot 1 to 2, from JUnit 4 to 5, to do code cleanup things, to do security vulnerability fixes. We want those recipes to always be Apache licensed and open source. Framework authors are going to develop the recipe, so the Spring team will develop the recipe that will move you from Spring Boot 2 to 3, or the Quarkus team at IBM or Red Hat would develop the recipe that’d move you from one version to another.

What Moderne does commercially is we take those recipes and we run them at massive scale, so I could take that recipe and run them against tens or hundreds of millions of lines of code, and you can see that, the impact of that recipe running against your whole organization’s code base.

Alan Shimel: Fair. And so you mention – how did – it’s not Modern. It’s Moderne. Correct?

Jonathan Schneider: Yeah, we call it Moderne. Yeah.

Alan Shimel: Moderne. So that’s the name of the company.

Jonathan Schneider: It’s the name of the company, yeah.

Alan Shimel: And OpenRewrite is the open source aspect of it or –

Jonathan Schneider: That’s right.

Alan Shimel: – owner of the solution. So let’s get into the mind of the entrepreneur here a little bit, Olga. Having worked at Pivotal and EMC for years before this, you saw this issue. You saw this problem. There’s got to be a solution. When did you say, you know what, this is something worthy of starting a company, right? When I was starting companies, one of the big questions is, is this a feature or a product? Right? Is it just a feature of someone else’s product, or is it truly a product in and of itself? And that makes a big difference in, obviously in what you’re building and what your aims and all of that. Olga, I’d like to hear from you. Feature, product, how did – what was kind of your thought process in saying, you know what, this could be its own company?

Olga Kundzich: I think this, something like this is essential for managing modern cloud-native applications. These are becoming, the applications sort of become a glue code teaching all of these third-party components. They evolve and change at their own pace, and developers really right now are just restitching those things back together, upgrading CVs, upgrading versions, and it takes a really significant amount of time just to – sort of anecdotally we hear from people that 20 to 30 percent of their time, engineering time, is just now dedicated to these tedious migrations. So if we can automate this, we can unlock innovation, productivity of engineering organizations, and help a lot of businesses actually innovate.

Alan Shimel: Got it. Jonathan, what about from your end? Well, let me ask you both. Is this your first time starting a company?

Jonathan Schneider: It’s first time starting a company, yeah. I think it’s real special to me. I think one thing I love about this business is that we’re really after helping organizations fix their code, and our outcome and our future success is tied directly to how much code we’re able to fix, how much help we’re able to provide. We’re not about reporting and saying like, you know, here’s the problems that you, engineering team, need to fix. When we partner with an organization, we’re kind of in the trenches with them getting these issues off their plate.

We talked to one organization recently – and this is why I think it’s a product and not a feature. We talked to one organization recently and they say we just look at our top ten issues reported by a series of static analysis tools they have in-house, and it says, well, it’s gonna, these tools estimate it’ll take 1,700 developer days to fix these top ten issues. So that’s like 4.8 years’ worth of developer time to fix those top ten issues that they have, and those aren’t false positives. Those are just literally top ten critical problems they have right now. So we developed recipes for a lot of those, and their engineers said, you know, “We estimate it would take us five days with these recipes to apply that change and be done with it.”

When I think about 1,700 developer days or 4.8 years of time, what that really means to me is infinity, or like it means that the engineering team is never going to get through that backlog of issues. Five days seems like it is possible, and that’s, there’s this line we have, the, basically software grows until it can no longer be maintained, and I think our business is in keeping that software in a maintainable state so that the business can continue to innovate and thrive.

Alan Shimel: Absolutely. So companies launch now – we didn’t even mention the website. Shame on –

Jonathan Schneider: Yeah.

Alan Shimel: What’s the website?

Jonathan Schneider: Yeah, so the website is moderne.io, so it’s modern with an E.

Alan Shimel: Can you spell that, Jonathan? M-O- –

Jonathan Schneider: Yeah, it’s M-O-D-E-R-N-E, so modern with an E, dot I-O.

Alan Shimel: Dot I-O.

Jonathan Schneider: Yep, that’s right. We do have a restricted beta going on right now that you can just sign up for that on that website, and we’ll do an invite to you and you can see how we can apply these recipes across tens of millions of lines of code.

Alan Shimel: Absolutely. Are you working with CDF and the Spinnaker community?

Jonathan Schneider: We’re really in an adjacent product space now. I think there’s a lot of value to operational automation, what Spinnaker is doing, what different APM vendors are doing. I think we were working in that and we saw just an adjacent pain point that we just decided to go after instead.

Alan Shimel: Good stuff. Well, guys, I want to wish you nothing but a lot of success with this. It’s always, you know, I gotta be honest with you. I always enjoy interviewing new companies coming out of stealth and beta, first-time entrepreneurs, ’cause you make the world go around. And good luck. Keep us posted. Come back on and tell us more as you, as the story continues to unfold here.

Jonathan Schneider: Yeah, look forward to talking again soon.

Alan Shimel: All right.

Olga Kundzich: Thank you.

Alan Shimel: Jonathan and Olga from Moderne, M-O-D-E-R-N-E, dot I-O, here on TechStrong TV. We’re gonna take a break. We’ll be right back.

[End of Audio]

November 10, 2021
AWS BugBust Challenges Developers to Set World Record for Bug Busting at re:Invent 2021
Software bugs are irksome, time-consuming and can be one of the most expensive software development costs for any company on an ongoing basis. Software Testing News cited a study that found the cost of poor software quality in the United States alone was estimated to be $2.8 trillion dollars. Let that sink in. $2.8 trillion dollars. And 18.22% of that cost was technical debt. Pair that with the fact that Watts Humphrey¹ estimated in his book, A Discipline for Software Engineering, that, on average, software developers make 100 to 150 errors for every thousand lines of code.

Suffice it to say that the costs of poor software quality are significant.

Welcome to the First Annual AWS BugBust re:Invent Challenge

AWS is making a commitment to help software teams around the world improve software quality with their global AWS BugBust Challenge. The first annual AWS BugBust re:Invent Challenge is right around the corner.

The challenge, taking place from November 29, 2021 at 10 a.m. PST through December 2, 2021 at 2 p.m. PST, enlists Java and Python developers to collectively fix bugs and eliminate technical debt using Amazon CodeGuru. Within this time frame, registered participants across the globe—participating virtually—and those present onsite at the BugBust Hub at the AWS re:Invent Expo, can compete to fix as many bugs as possible to win prizes, glory and claim the title of the Ultimate AWS BugBuster. For each bug that you fix, you receive points based on the complexity of the bug. The more bugs you fix, the more points you will gain and the higher you will climb up the AWS BugBust Leaderboard. The live leaderboard will track each participant’s progress and showcase the number of bugs fixed and points received.

Be a Part of Setting a Bug-Busting World Record

At re:Invent, AWS also is looking to set a Guinness Book of World Records record for the largest code-fixing challenge ever. To date, there are no existing records for an event of this kind. Fix at least one bug to qualify to be part of setting the Guinness record. You can join onsite or online. Be part of the excitement of trying to set a world record while winning prizes and gaining recognition!

Milestone Prizes

While developers will go head-to-head to win the title of the Ultimate AWS BugBuster, they will also have the opportunity to win prizes for their milestone achievements. The Grand Prize will be $1,500 in cash.

There will be five key milestones that developers will be working towards:
- First milestone—1 point—AWS BugBuster Fly Swatter
- Second milestone—50 points—AWS BugBust branded sanitizer (BugSpray)
- Third milestone—150 points—AWS BugBust glow-in-the-dark Bug Jar
- Fourth milestone—300 points—AWS BugBust hoodie
- Fifth milestone—500 points—AWS BugBust branded Echo Dot
- Grand prize—$1,500 for the top BugBuster
In addition to the milestone prizes, all developers who have contributed toward setting the record for the world’s largest code-fixing challenge will receive an exclusive AWS certificate. The bugs fixed at this live event will count toward the global total which the AWS BugBusting team will have front and center at the event.

AWS BugBust Hub

The BugBust Live Challenge will be hosted in the BugBust Hub. The Hub will provide a fun and relaxing environment for developers to fix bugs and ask questions of the AWS BugBust SWAT team as they get started on the BugBust Live Challenge. Not on-site at AWS re:Invent? No worries—developers can still participate and win prizes virtually, too!

For more information and to pre-register for the AWS BugBust re:Invent Challenge, please visit the AWS BugBust website.

1 Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process program and provided the vision and early leadership for the original capability maturity model (CMM). He also is the creator of the personal software process (PSP) and team software process (TSP). He was awarded the National Medal of Technology―the highest honor given by the president of the United States to America’s leading innovators.
November 3, 2021
GitHub Expands Developer Productivity Tools Portfolio

During the online GitHub Universe 2021 conference, GitHub today unveiled a bevy of updates intended to boost developer productivity by making it easier for developers to write code faster and collaborate more easily.

The GitHub Copilot tool that GitHub developed in collaboration with OpenAI, a research and development lab, to help developers write better code faster is being extended via a technical preview to add support for Java and the integrated development environment (IDE) JetBrains.

In addition, the Codespaces tools that GitHib makes available to pre-configure development environments is being extended to include support for devcontainer feature composition, the GitHub command line interface (CLI) and REST application programming interfaces (APIs) along with additional access controls.

GitHub Actions has also been updated to add support for deployments using the OpenID Connect standard in addition to providing access to deployment environments to simplify approvals, improvements to reusable workflows and auto-scaling functionality for self-hosted runners.

There is also now a Command palette tool in beta to help developers navigate GitHub along with a public beta of a GitHub Issues tool that makes it simpler for developers to filter, sort and group issues and pull requests. Additional features that have been added since GitHub Issues was first previewed include iteration support, reporting and data visualization tools and the ability to employ it across public projects.

Finally, GitHub is adding, in beta, support for Ruby as a programming language that CodeQL analysis engine can now scan for vulnerabilities along with the ability to customize permissions for accessing GitHub Enterprise Cloud.

Ryan Salva, vice president of product management for GitHub, said collectively GitHub is committed to making developers more productive by, for example, autocompleting code as developers write. Support for additional programming languages will also be forthcoming in the months ahead. The goal is not to leverage AI to replace developers but, rather, eliminate the drudgery that gets in the way of developers becoming more creative, noted Salva.

There won’t come a day any time soon when developers won’t have to type to write code, but it is possible to leverage AI to provide a type-ahead capability that reduces coding errors, added Salva.

The goal should be to enable developers to create more application experiences at a time when more organizations than ever are consuming applications that drive a wide range of digital business process transformation initiatives, said Salva.

As part of that effort, Salva noted it’s also critical to reduce the amount of friction developers encounter writing code starting with setting up the development environment itself.

It’s not clear yet what impact all the focus on developer productivity and collaboration will have on the rate at which applications are being built and deployed. However, as developers become more productive, the number of application development projects that can be launched simultaneously should increase. In fact, there may come a day when applications are being built faster than organizations can deploy them without adopting continuous delivery best practices that rely on higher levels of automation to install software.

Regardless of that application delivery challenge, however, it’s a problem most organizations right now would consider themselves fortunate to have.

October 27, 2021
Managing Technical Debt is a Balancing Act

Technical debt is a nightmare for product managers. It can slow down teams and inhibit response time for delivering quality products to market. Yet, there are times when technical debt can be beneficial; but turning it from a headache to a positive is a balancing act.

Nimble project managers and developers should strive to develop an equilibrium that balances creating, reducing and accepting technical debt. The good news is: That’s attainable.

The Shape of Technical Debt

It’s essential for PMs to understand how technical debt can arise so they can identify its characteristics and manage the amount to carry or avoid to the team’s advantage.

Laying too much brick and mortar will take software features too long to develop. It risks their rollout arriving well past due dates. But fixating on speed threatens to underdeliver on functionality. Circumstances like these will diminish the ability to deliver powerful results over time.

Similarly, ignoring the power of third-party solutions to slot in and satisfy customer needs and speed-to-market is outdated thinking. For example, software like embedded analytics can arrive off-the-shelf to complete an architecture task quickly and affordably while freeing up the team to address other challenges. Remaining agile with all options available to the team is critical.

Overall, the project manager’s goal should be to identify the indicators of technical debt and hone their skills to address each type.

Building Architecture

When a team is tasked with delivering new features or functionality, building upon the existing structure to support the new capability is not unusual. Lack of foresight or diligent planning about what’s necessary to enable this function can be a critical oversight that leads to a void in need resolution, i.e., incurring debt requiring payment.

Speed versus Quality

Delivering at the speed of modern business often means facing time constraints that can impact the quality of work. Faced with such limitations, teams may take shortcuts. Ultimately, those shortcuts can lead to an increase in technical debt.

Quantity versus Speed

On the opposite end of the spectrum, eagerly attacking a project that requires significant lead time can result in overbuilding. This leads to a different form of technical debt. Longer projects can be affected by technological change—an evolution that makes some previously completed structures outdated. Debt takes the form of teams forced to return upstream to make necessary changes when they should instead remain downstream.

Near-Sightedness

Unlike the oversight or overbuilding described above, if the team fails to consider future needs and focuses only on current tasks alone, it risks creating debt that arises by starting from scratch. If teams don’t anticipate the next feature or prepare for future functionality while in development, they will likely pay for this near-sightedness down the road.

To Build or Buy

Developers want to build. It’s what they do. But it’s not always in the organization’s best interests. When a team faces complicated requirements, is extended beyond its capabilities or is simply well outside its repertoire, debt can be avoided by looking toward existing platforms that fulfill its needs. In such instances, a third-party solution saves significant time and money. For example, an embedded analytics tool built with the latest technologies and deployed turnkey frees the development team to remain focused on its expertise and apply its talents there. Think: Does the team need to invent a new wheel, or does one already exist? While choosing the former risks taking on debt, selecting the latter holds the promise of reducing it.

Manageable Debt

Still, technical debt can be a benefit.

Consider this example: You want to roll out a platform that delivers to the customer and market, but it’s a ground-breaking product. You don’t yet know everything you want or need to know about how end users will engage with it and what they’ll ask it to do. In situations like these, it’s reasonable to get the functional framework of the software into the hands of the market so that you can absorb reams of feedback, return to the platform and then build out or fine-tune its features and functionality. Actions like these are wise. PMs haven’t mortgaged the farm for a bag of magic beans—they’ve taken on a reasonable amount of debt to fertilize team knowledge into a product that will ultimately deliver the most value.

Recognizing technical debt and its approach, avoiding or accepting it accordingly and then managing it with deliberate efforts to pay it down within acceptable limits is where PMs want to be. If you invest in paying it down or seek and accept third-party solutions to avoid it altogether, you’ll maintain team focus and velocity on the projects they excel in.

October 26, 2021
A Blueprint for Securing Software Development
Software development has changed dramatically in recent years, as technologies like DevOps, application containers, and cloud-native transform how software is built and distributed. Unfortunately, attackers have been paying close attention to these changes, and have retooled their attack strategies to take advantage of relatively weak security controls in software development and build environments. Attackers recognize that security teams are more focused on protecting infrastructure and less focused on software development and supply chains. This is how damaging attacks like SolarWinds happen – and it’s likely that attackers will strike again to yield even more successful outcomes.

A new approach is needed to secure the software development pipeline. What’s more, this approach needs to be put in place by the engineers developing the software—and not by information security teams. Engineering teams need to be responsible for design and implementation while giving security teams visibility and assurance that controls are operational and that policies are being enforced.

A new blueprint for securing the pipeline centers on a flexible set of controls that secure the software build pipeline by ensuring that authentication and authorization are properly managed, that the integrity of software artifacts are tested at appropriate stages and that controls are placed on third-party and open source solutions incorporated into the software. The result: Software innovation and delivery at lower risk of supply chain tampering, and reduction of attacks during development.

A Pragmatic Design Philosophy

This modern software security blueprint is based on the following design philosophy:
- Least-privilege: Only grant the access and permissions required to accomplish a job, and no more.
- Immutability: Artifacts and infrastructure are not modified after deployment to an environment. If a change is required, it’s done in the image or script in the development environment and then promoted through the higher environments.
- Everything-as-code: Infrastructure, security policies and other parts of the pipeline are also implemented as code and subject to the same controls as the software artifacts.
- Traceability: All changes, whether to infrastructure or business code, are version-controlled.
Controls Blueprint for Software Development Pipelines

The basis for this software security blueprint centers around a set of 15 controls that are built for modern development pipelines where developers, pipelines and execution can happen anywhere in the world.

Control one: Restrict administrative access to CI/CD tools. Ensure that only authorized people can make administrative changes to the CI/CD system, which prevents unauthorized changes to pipeline definitions.

Control two: Only accept commits signed with a developer GPG key. Unsigned code commits are challenging, if not impossible, to trace and pose a risk to the integrity of the codebase.

Control three: Automation access keys expire automatically. By ensuring that access keys used by automation expire periodically, developers create a shorter window of attack when keys are compromised.

Control four: Reduce automation access to read-only. CI systems should have read-only access to source code repositories following the principle of least-privilege access.

Control five: Only dependencies from trusted registries can be used. By configuring the dependency manager to only allow connections to an authorized list of registries, attacks can be blunted by keeping malicious packages in public registries from entering the pipeline.

Control six: Any critical or high-severity vulnerability breaks the build. Supply chain attacks may introduce code with vulnerabilities into the software pipeline. Static application security testing (SAST) helps to identify serious security issues, including poor cryptographic practices, hard-coded credentials and injection vulnerabilities.

Control seven: Artifacts are stored in a repository in development, staging and production. This control helps to enforce the immutability of the artifacts so they can be compared in the development, staging and production repositories.

Control eight: Validate artifact digest. Before an artifact is deployed in any environment, its digest should be validated against the artifact in the repository to ensure that it has not been compromised.

Control nine: Pull requests require two reviewers (including one default reviewer) and a passing build to be merged. In addition to supporting good coding practices, this control also helps ensure that no commits are made without competent human oversight.

Control 10: Artifacts in higher repositories are signed. Requiring artifacts to be signed in a repository throughout the process ensures visibility and traceability for whatever is deployed to production.

Control 11: Available container images don’t have any high or critical vulnerabilities. Just as applications need to be tested for vulnerabilities before being placed in production, so do the container images into which they are packaged for deployment. Container images could have open source vulnerabilities if they contain open source software.

Control 12: Validate artifact signatures and digests. Validating the signature of the artifact against the digest ensures that the artifact was not tampered with in the repository and that the artifact being deployed is the same one that was tested.

Control 13: Scan deployed images in production. This helps to ensure that the prior controls were followed for all software in production.

Control 14: Validate Kubernetes resource manifests. If the resource manifests are tampered with, they could be tricked into deploying a container of the attacker’s choice.

Control 15: Ensure build environments are ephemeral and immutable. Build environments should be defined in code with automated creation and teardown and a fresh environment created for every build. Build hosts should not be accessible using interactive logins.

We believe this blueprint provides engineering teams with an actionable architecture that security teams can rally behind and support. By adopting these standards, engineering teams are promised the delivery of assured software at lower risk of supply chain tampering, reduction of attacks during development and manipulation in staging and production.

Here’s what it looks like:

To learn more about the suggested blueprint, read our GitHub post about the project. Our goal is to prioritize speed and agility for software development while incorporating a security-always mindset.
October 19, 2021
Building DevSecOps With Value Stream Management
As teams develop software, testing for potential security risks and flaws is mission-critical, just as it has always been. Yet, cyberattackers continue to exploit code vulnerabilities as open source code remains the foundation for the majority of commercial applications across all industries. Security firms are churning out solutions at an aggressive rate, and both project managers and their teams hope they can purchase some bolt-on tool or license a service to take care of security, painlessly. In the end, vulnerabilities still occur.

The most effective pathway to secure software code has always been to eliminate vulnerabilities. The question today is, “What is the best way to achieve that goal given such an accelerated, threat-laden landscape?” Before we dig into that answer, let’s take a closer look at the problem.

Software Security Is Everyone’s Issue

Even the largest organizations, from Adobe to Microsoft, have been humbled by the number and scope of code vulnerabilities that have been overlooked—and therefore escaped into public release—due to the frenzied pace of software updates. Here’s just one example:

On May 11, 2021, Adobe issued a security update for Adobe InDesign that addressed multiple critical vulnerabilities. “Successful exploitation could lead to arbitrary code execution in the context of the current user,” the security bulletin read. “Arbitrary code execution in the context of the current user” is cybersecurity speak for “an attacker can execute arbitrary commands or code on a target machine or process.” Arbitrary code execution vulnerabilities are known to be one of the top attack vectors that lead to system penetration resulting in data breaches.

Given the enormous effort companies and their software teams are exerting today, and the importance of avoiding software flaws in the current threat landscape, how is this happening? It doesn’t help to have publicly available lists of software vulnerabilities posted on the dark web and CVE (ironically, a database of vulnerabilities launched to help companies improve their cybersecurity). Hackers — from solopreneurs to nation-state teams — are having a field day with this information.

Rearranging the Puzzle Pieces Doesn’t Guarantee Security

In an attempt to resolve this challenge, industry professionals are coining new terms and calling for new approaches. One I have seen promoted recently is “SecDevOps” rather than “DevSecOps.” With SecDevOps, they assert, security is first—conducted at the start of the project and maintained all the way through.

This approach isn’t new—it’s essentially a variant of shifting left, which for more than a decade has been an established mechanism in software testing for finding flaws and “failing faster.” In my experience, while failing earlier and faster with any software endeavor has considerable value, it is not automatically going to highlight all security challenges and enable their resolution.

It is just as important for DevSecOps teams to collaborate and work together, not only to support development and operations, but also to ensure security, compliance and governance are built into every piece of code.

Insight Is Preferable to Blind Interpretation

Unfortunately, achieving that collaboration productively comes with challenges. DevSecOps teams need rich, real-time visibility into code vulnerabilities, early, so they can act on that information and update code as it moves through the pipeline. To do that, they need actionable insight—not a motley assortment of data that’s open to interpretation.

In value stream management, we have seen firsthand while working with our clients that several techniques can be applied to eliminate vulnerabilities more quickly and effectively. All of these approaches hold value, whether a firm is seeking to deliver a new product to market or secure its current software pipeline.
- Amplify feedback loops. Continuous feedback loops—from DevSecOps tools, for example—give developers more detailed insight into their code’s vulnerability.
- Run security scans. Give testers the ability to run security scans on their code even before it is committed to identify security vulnerabilities as early as possible.
- Leverage reporting and analytics. Gaining early access to as much insight as possible makes teams and management more confident regarding swift action to resolve code deficiencies.
These approaches also support governance and compliance initiatives. As a bonus, they boost software quality, as well.

The Business Case for Built-In Security, Governance and Compliance

As mentioned earlier, these activities are integrally connected with the effort to eliminate code vulnerabilities. In case you are thinking, “This is obvious,” take a moment to reflect on this statistic: 60% of data breaches involved vulnerabilities for which a patch was available but not applied.

The sheer scope of the problem also underscores the lack of attention to security and governance—and any compliance requirements that accompany it.

Half of websites in production have high-risk vulnerabilities, and 82% of these are located in application code.

The high percentage of errors in source code suggests it was not checked for vulnerabilities during development, signaling that developers focused on app functionality and gave short thrift to security. This often means they don’t have a program for governance and compliance, either.

In my experience, a primary reason for these failures is that teams don’t have actionable information from the activities mentioned above, such as real-time feedback from DevSecOps tools. Developers need this insight when they are resolving sprint backlogs. Information relating to high-level security issues must be available so it can be addressed, with issues prioritized and resolved, and not left sitting in siloed DevSecOps tools.

In many ways, DevSecOps is in the same stage of transformation as DevOps was a decade ago. Teams are frustrated by needs they do not know how to meet, and they hope for fast resolution in the form of tools and solutions. As with virtually every other software challenge over time, there is no replacement for getting in the trenches and fixing the problem rather than placing strategic band-aids.

If you are not subject to compliance mandates and therefore dismiss the value of software governance, consider this: If your team misses a software vulnerability that results in a major data breach because you didn’t have the insight to identify it—or the governance to ensure it was addressed—your firm may not recover. The imperative for software security—and the governance that helps ensure it stays that way—should be sufficient for organizations to take vulnerabilities seriously.

Effectively applying the insight gleaned from software code reporting and analytics is the surest way to eliminate vulnerabilities. As an added benefit, the reporting and analytics that informs the software effort can also make the case to upper management for the value of launching future improvement initiatives.
August 27, 2021
How to Optimize Data in Software Development

Data can drive significant business value for every company. Globally, we are collecting more of it than ever before, and it keeps growing—from 45 zettabytes in 2019 to a projected 175 zettabytes by 2025, according to IDC. However, companies are struggling to monetize all the personal, behavioral, engagement and transactional data from customers and operations and turn it into actionable intelligence to drive their digital strategies. Leveraging insights from your data is critical for success and the development of new digital solutions to better serve customers, grow sales, improve operations and more.

Data helps organizations develop the right software for the right customer at the right time. Data-driven organizations are 23 times more likely to acquire and retain customers than their peers, and are growing at an average of more than 30% annually, according to Forrester.

Organizations with a deep and dedicated focus on data and analytics tend to follow three common paths to successfully drive their software development initiatives.

Discovery Matters

It is nearly impossible to draw value, understanding, and insights from the massive amount of data businesses collect without a proper discovery system in place. Having a comprehensive process of collecting data from various databases and silos and consolidating it into a single source that can be easily and instantly evaluated is critical for any software development project.

During client engagements, data scientists perform deep-dive research into clients’ data pools and workflows to support client roadmaps. We recently partnered with a global e-commerce company to create a recommendation system for their customers. The discovery process allowed us to verify the feasibility of recommended products using their existing data before moving ahead with the project. Using machine learning, the team was able to clean and analyze information from multiple angles. With that knowledge and confidence, the rest of the development project proceeded quickly knowing the data was in place and the project was viable.

Align KPIs

Software development metrics help organizations and their partners track and measure how an application is performing and how effective the development team is in its work. IT organizations rely on a range of KPIs to fully understand software engineers’ progress, as well as gauge software quality including performance, engagement and user satisfaction. While each engagement is different and requires a different set of KPIs, ensuring that the organization and development team are on the same page is crucial.

During the e-commerce project, success was measured through conversion and user retention rates. Other KPIs that are regularly used include developer productivity and performance metrics like cycle time and team velocity, and software developer metrics like response time, usability and UX data, among others.

Deploy Agile

By using agile methodologies at all stages of development, developers are able to focus on business results, not just architecture and new technologies. A similar agile approach can also be applied to data management. When it comes to data science, it’s all about extracting useful information from raw, structured and unstructured data and implementing machine learning models to analyze vast amounts of information. This process requires more creativity and is a key driver for understanding potential risks and failures over the course of any given project.

With agile, data models and analyses are broken down into manageable bite-sized chunks that can be built and tested quickly—the same way software is developed. If the analytics do not yield the expected results, data scientists see the failures immediately and can correct their course. They could ask the team to analyze different data sets, adjust the models, tweak algorithms or make an educated decision about the project’s viability.

A multinational credit company took this approach to the next level when it used agile to develop a new, big data hybrid cloud platform. After anonymizing, aggregating and storing information in a data lake, the team quickly realized the database it was planning to use was limited to a certain number of partitions and entities. By running agile sprints and developing and testing the minimum viable product (MVP) continuously, the team was able to seamlessly switch to a new database that had more scale and functionality.

The value of data is only going to increase with time. Data-driven organizations embrace the use of data and analytics to gain unique business insights to support their software development projects and overall business. By focusing on the data in each and every development project, companies have a tremendous opportunity to gain a competitive advantage and grow their businesses.

August 26, 2021
Measuring Value Streams by Analyzing Flow Metrics

There is increasing pressure and demand for IT administrators to bring software to market quickly and cost-effectively. To achieve that goal, IT departments frequently compile various metrics that measure specific development processes.

Data and metrics are important tools, but administrators sometimes don’t think to look at projects through a wider lens—by measuring total production workflows. This can curb production and adversely affect business outcomes as inefficiencies go undetected across the value stream.

In other words, total visibility across the entire value chain is needed to accomplish lean project management and optimize DevOps workflows.

Let’s talk about the different kinds of flow metrics, why they matter and how to begin measuring them.

Flow Metrics: What do They Mean?

Flow metrics indicate the rate of value delivery with regard to desired business outcomes. This allows organizations visibility into production at a macro level so that they can make more effective decisions. Flow metrics can also produce an analysis of historical performance over time, which can be valuable for businesses that focus on continued growth.

IT leaders now widely use flow metric analysis to bridge the gap between business teams and technology, because it can uncover a variety of problems that affect critical objectives. For instance, teams can identify prioritization challenges, why projects take longer than expected, pinpoint technical debt and more.

When evaluating flow metrics, IT departments measure individual work units—also known as flow items—that clients or product teams hand over to their colleagues. This may be a request for a new software feature, a security flaw or something that needs a fix.

What Are the Different Kinds of Flow Metrics?

With a better understanding of flow metrics, we can now delve deeper into the five flow metrics that organizations should assess throughout the development process.

1. Throughput

Throughput measures the rate at which total number of flow items are completed. By measuring this, throughput can determine the total amount of value attained and distributed during a specific project.

Throughput is generally measured week-over-week. Measuring and evaluating throughput on a historical basis also helps work out how clashes in priorities affect value overall.

Optimizing throughput results in greater end user experiences and customer satisfaction, which naturally drives revenue and growth.

2. Cycle Time

Cycle time is the speed at which an IT team can deliver value. This means timing how long it takes for flow items to progress from work start to work complete, taking into account active and wait times.

Cycle time is just as important as throughput when it comes to driving revenue and growth. Measuring cycle time can streamline the process of determining project estimates and allocating resources, resulting in stronger workflows and enhanced efficiency.

3. Flow Efficiency

Flow efficiency is the proportion of active time to wait time. Measuring flow efficiency uncovers where roadblocks are happening and whether process waste is rising or falling. The desired flow efficiency rate should be higher than 15%.

Most flow time comes from waiting, resulting in roadblocks and increased production costs. Measuring flow efficiency can enable teams to pinpoint when workflows are taking too much time, and they can then take active measures to accelerate individual processes.

4. Work in Progress

Work in progress involves measuring demand. Teams achieve this by measuring the amount of flow items either pending or in active development within a value stream. Measuring work in progress generally enables IT leaders to identify whether value streams are overused or underused.

Nobody’s perfect. That’s why leaders have to be conscious of how each employee’s time is being used. By doing so, they can systematically assign workloads and enhance quality where required. This, in turn, lowers burnout and turnover while also cutting down on mistakes that need to be reworked.

5. Work Profile

Measuring work profile is important when determining priority alignment. It’s analyzed as a ratio of the four other flow items completed in a specific time period.

Assessing work profile allows for optimal quality and productivity. This raises customer experience (CX), which results in better retention and reviews.

Why Should I Track Flow Metrics?

In the past, DevOps professionals largely went without the necessary tools for tracking and enhancing flow metrics, but recent improvements in tracking these metrics have made the process much more efficient and easy.

There are three key reasons for flow tracking:

1. Boost Communication

A lack of communication can be a common issue between business and software teams. Flow tracking enables IT administrators to delve into flow metrics and gain insight into the value stream. This helps teams provide accurate project estimates along with real-time updates, which makes communication with stakeholders much easier.

2. Determine Desired Business Outcomes

Having total visibility across a value stream helps IT and business leaders cooperate on identifying and prioritizing key projects and establishing goals.

Improving software quality could be a goal, for example. Teams can examine various flow metrics to determine what is causing issues in software quality, how to fix those issues and how prioritizing adjustments to software quality could affect other workflows.

3. Act on Intelligence

Software organizations spend a lot of time and money attempting to expedite software development. They hold meeting after meeting, hire consultants or even bring on new team members, but the solutions they need to streamline workflows can be simple. They just need to be discovered.

Organizations can gain total and real-time visibility into the value stream with flow tracking. This makes it quick and simple to act on intelligence and enhance development, leading to accurate, data-driven decisions that don’t require guessing.

Elevate Your Value Stream With Flow Metrics

Achieving optimal efficiency in workflows requires end-to-end visibility, which is made easy by analyzing flow metrics.

Using flow metrics to maximize the value stream improves visibility, accelerates development and cuts software production costs.

August 16, 2021