Last December, I made some rather public declarations about which software stability trends we’d see this year. Turns out, I’m not half bad at stability predictions (although I’m unlikely to add “prognosticator” to my CV). Before I try my luck again and tackle 2020, here’s the round-up from last year, including my original predictions and an assessment of what actually happened.

How we fared in 2019

Prediction #1: Stability will be adopted as a KPI. 
I’ll admit, in my exuberance about stability, I overshot this assertion. While most companies haven’t adopted stability as a KPI yet, I’m happy to report that early adopters and thought leaders are using—and experiencing great success with—stability metrics. Give it another year or two, and this one will come to fruition.

RELATED CONTENT:
Gartner’s top 10 technology trends for 2020
What software will be built in the new decade?

Prediction #2: Standardization of QA tools will occur.
Success! QA tool standardization hit mainstream levels, thanks in large part to the adoption of continuous integration/continuous delivery (CI/CD) practices and the automation of tasks like unit testing and linting. 

Prediction #3: Phased rollouts and canary releases will be adopted.
Another success! Companies shifted from “thinking about” to full-on adoption of these release practices. Phased rollouts are now supported in both the iOS and Google Play stores, which means many mobile apps are released as such, while web development is following suit, thanks to Jenkins and Microsoft. Plus, startups like LaunchDarkly have secured huge amounts of financing to continue testing phased release rollouts. 

Prediction #4: App stability monitoring will replace APM and bug tracking tools.
Much like my first prediction, this one’s on the right trajectory but needs more time. The market isn’t fully developed, but 2019 demonstrated that an increasing number of modern enterprises are discovering the benefits of stability monitoring.

Four stability predictions for 2020

With 2019 heading rapidly into the rearview mirror, there are several stability trends and organizational rumblings I’ve observed this year that fuel my predictions for the coming year.

Prediction #1: Adoption of health scorecards 
We all know that a multitude of issues can interfere with the customer experience. While bugs and crashes play a large part in upsetting users, events like application freezes, memory leaks, ANRs, and out-of-memory sessions also need to be addressed by engineers. As such, organizations are waking up to the fact that a more holistic approach is required for monitoring software. 

However, to understand where we’re heading, let’s take a moment to consider where we’ve been and the evolution of error tracking and monitoring:  

  • We started with error logging, i.e. centralized logs in one place.
  • Next came error monitoring, which provided structured error data, grouped by root cause with diagnostic information.
  • Today, stability management allows organizations to receive actionable insights about releases and make data-driven decisions about fixing bugs vs. building features. 
  • And I believe software health is the next step. 

Software health builds perfectly upon stability management by measuring those additional variables (like app freezes and memory leaks) that impact the customer experience. By comparing variables across releases, features, and A/B tests, engineers can gain actionable insights into which problems should be prioritized and fixed to improve the overall software health.

All the challenges that impact the customer experiences can be rolled up into a single stability score, but it’s also important to break down the components by delivering a Health Scorecard. Think of it as a report card: You get an overall GPA (stability score), but there are also grades (metrics) for each subject (software health events). 

This breakdown enables engineers to understand exactly what’s happening and makes it actionable. Focus can be placed on improving the areas where software is performing the worst.

These additional insights are exactly what engineers need, which is why Health Scorecards will become a must-have in the year ahead.

Prediction #2: Shift in ownership from operations to development
Historically, the running of apps has been kept separate from the building of apps. While developers put their efforts into the architecture and features, DevOps and infrastructure teams sat on the frontline of application performance. As such, Application Performance Management (APM) tools worked well for detecting performance issues and highlighting error-prone apps.

Then mobile apps came along, and the dynamics of building applications changed. Without any infrastructure to manage, product engineers not only developed the apps but naturally took over the improvement of them as well. 

Suddenly, rapid development, rapid iteration, and instant feedback became possible because the people running the apps were the same ones building them. With this role shift came the need for a different approach. APM tools, which were created for backend layers like Network, Storage, and Server, simply weren’t going to cut it. 

Instead, engineering, product, and QA teams embraced stability monitoring tools that monitor the front end, tie directly to the workflow, and enable them to focus on customer experiences on web and mobile apps. These stability tools make sense because any errors affecting the customer experience can be prioritized and fixed quickly by the right teams. 

As a nod to the power of stability, it’s interesting to note that backend and web teams have seen the benefits of stability monitoring tools and now want to take the same approach, both for building and running applications.

Prediction #3: Stability metrics in the boardroom 
The importance of the customer experience is not lost on those in the C-suite and boardrooms of modern organizations. Leaders are recognizing that many of the DevOps and engineering metrics they’ve relied on for years are outdated. 

For example, consider uptime availability. Any company that runs in the cloud is delivering a highly-available application these days. And, if a server does happen to go down, but the app continues to run on another without impacting customers, does it matter? 

The real metric that leadership teams should care about is software stability because it’s the one thing that directly impacts the end user experience. The questions that every C-suite and board member need answers to are: 

  • Is our technology healthy? 
  • Is it doing the job we want it to do?  
  • And, most importantly, does our technology work the way customers expect it to work? 

After all, if you aren’t focused on what keeps customers happy and engaged, then you’re probably aiming the ship in the wrong direction.

I predict that organizations will start to productize stability scores next year and use them to provide visibility across the entire organization. With a common language and a single metric with which to discuss software health, every team will have complete insight into where things are at, what must be achieved, and what the C-suite and board will use to hold everyone accountable.

By the way, this scenario is already happening. Modern organizations like HotelTonight are using stability targets and stability metrics with their boards and C-suite leaders to illustrate exactly what’s happening with customers and to aid in data-driven decision making.

The fact is, if you have poor stability, your app is going to disappoint customers, which is why it’s never been more critical to find a common way to talk about software health.

Prediction #4: Stability as the data-driven layer of the SDLC.
If you look at a typical schema for the software development life cycle (SDLC), it’s illustrated as an infinity loop or circle where planning, analysis, and design lead to implementation, testing, and integration before heading into the maintenance phase. 

I don’t believe that’s how it really works. Humor me for a moment and think of the SDLC as a straight line. At each point, there’s an escape hatch so that, if something fails, you go back to an earlier point. It’s almost like a game of chutes and ladders. You climb to the next phase or slide back to the last one. 

What’s missing from the SDLC is visibility into the production side. Organizations tend to fly blind once they’re in production because Jira and Jenkins live almost entirely on the left-hand side of my straight-line SDLC. But the far right-hand side is where customers are using it. On that side, you need stability management tools and software health monitoring from the moment a customer touches the software.

You also need a feedback layer that tells you whether you should give a build to customers, whether a beta release is stable, and what’s happening in a phased rollout that you want to test with 5% of your customers. In short, you always need to know what’s happening once your  software is in customers’ hands, which is delivered by adding stability as the data-driven layer of the SDLC. (Whether you want to play “chutes and ladders” with it is up to you.)

Vote software health in 2020
There are many reasons to be excited about software stability in the coming year. While I don’t think we’ll reach the top of the adoption curve in 2020 (probably needs another year or two), I do believe we’ll see strong acceleration and a significant increase in the adoption of stability management tools that promote software health. 

What excites me the most is realizing the organizational impact that software stability can have. It’s no longer a nerdy thing that engineers discuss but rather a significant metric that affects everyone and speaks to the overall health of your business. By making stability a boardroom and C-suite metric, you turn engineering parlance into actionable insights that leaders can base decisions on.

And that’s something we can all toast to in the new year.