Moderne: The Antidote to Software Maintenance Toil
Stop for a moment and think about the house you live in. The structure was built using an endless supply of materials manufactured by third parties. From the drywall, to the plumbing, to the electrical wiring, all the way down to the cement and rebar comprising the very foundation. It’s a complicated structure built from many parts. And those parts degrade over time.
Now think about when you want to do an upgrade – say a new extension off the living room. You start the project, but quickly realize you have to totally replace the subfloor in the existing living room first, given it has degraded and is no longer up to spec. So before building new, you’re stuck maintaining and fixing the old.
Welcome to software maintenance…
Some Nightmarish Realities About Software Maintenance
The analogy above doesn’t come close to the complexity of software maintenance, but it is effective in illustrating a simple point: how can you build new when you can’t even maintain?
How did we get here? Software development has undergone massive changes in the past several decades, which ultimately led to our current state of affairs:
- Applications are assembled and less than 20% of the code base is custom business logic. 80% of the code base is third-party components.
- The variety of those components – be it languages, frameworks, runtimes, libraries, APIs, webhooks to other services, etc. – is exponential.
- The sheer volume (lines) of code has exploded. Organizations have substantially more lines of code and source repositories under management than they did 20 years ago.
- Lastly, the rate of change for all of the above is… constant.
The continuous compounding of the foregoing factors causes software maintenance to be the proverbial firehouse. The dependencies within your code base are changing frequently – shifting sands under your feet. Vast amounts of mission critical enterprise software are built in aging frameworks – introducing new vulnerabilities and bugs daily. Technical architectural choices made at one time may become burdens down the line – be it scaling challenges or otherwise.
The list goes on and on, but one thing is constant: Fixing these issues feels hopeless for most organizations. Enterprises have a massive backlog of maintenance activities that just sit there, creating further technical debt. All the meanwhile, engineering teams are being asked to ship new features and add business value. But 30%+ of their time goes to maintaining the old and existing.
You Can Tell Me I Have a Problem – But I Just Want It Fixed
For the past decade plus, there has been a tooling focus on identifying code problems, particularly focused on Common Vulnerabilities and Exposures (CVEs). The explosion of Static Application Security Testing and Software Composition Analysis tools have put a spotlight on demonstrating the breath of third-party dependencies in code bases. One challenge is the signal-to-noise ratio for those tools is pretty off the charts. Sure you can tell me I have a CVE in a repo, but if that code isn’t used (or used for anything critical) it doesn’t really impact my operations. So why would I prioritize it?
However, the bigger issue is these tools just tell you that you have a problem and nothing more. Engineering teams are then just left with manually remediating the necessary changes. So even if a code search or scanning tool identifies a CVE that is of critical importance, ultimately it comes down to engineering teams to (1) identify each repo, binary artifact and deployed asset where that CVE is contained, (2) manually refactor the code in the repos, and (3) build and ship the new into production as a new artifact and deployed asset. Burning a CVE down to zero in an org is highly manual.
All of this takes a ludicrous amount of time to do manually. To give a precise example, at one Moderne customer SonarQube estimated 4.9 years of developer time to work to fix the top five identified CVE issues. Even small teams at SMEs have 20M+ lines of code. For large enterprises, that number is more like 500M+.
There is also one critical component to refactoring beyond just the drowning toil of the overhead: style. Engineering organizations have conventions for how code is built within the company. Ensuring those conventions are maintained is key.
Automation Is Key – But Nothing Good Comes Easy
So, we’ve established this is a huge problem – how do you automate in an accurate way that developers and engineering leaders can trust? Unsurprisingly, it’s a very nuanced problem that requires significant engineering skill and a deep understanding of software languages. Fortunately, we were lucky enough to be introduced to the team that has solved it!
In June 2020, Casey Rosenthal, the CEO of Verica and former Head of the Traffic & Chaos Teams at Netflix, introduced Nick to Jonathan Schneider, formerly on the Netflix Engineering Tools Team before he went on to join the Spring Team at Pivotal and further on to Gradle Enterprise.
We quickly connected with Jonathan. He walked us through his experience building OpenRewrite (repo, docs), which was proven at scale at Netflix. Jonathan had an incredibly in-depth, analytical framework on the needs for this solution. The ideation was that the high-level user objective is to promote change, to wipe away as much technical debt as possible to accelerate feature development. Importantly, he emphasized the product needs to focus on accuracy and accountability, which broadly requires:
- An asset inventory comprised on info on all assets across the software lifecycle (source code, binary artifacts, deployed assets) in order to understand current state and progress of a change campaign
- The ability to fix code and dependencies, at scale, automatically
Jonathan shared that he tweeted a teaser video of one auto-remediation in early 2020, and desperate enterprise Java developers zipped up their apps (source code!) and emailed them to Jonathan!
We left our first meeting incredibly impressed and set off to introduce Jonathan to potential design partners for the product, while Jonathan spent time looking for the perfect co-founder – Olga Kundzich. Olga and Jonathan worked together at Pivotal, where Olga was the product lead for Spinnaker. She was also heavily involved in data protection at EMC and the perfect complement to Jonathan. In addition to their impressive technical depth, Olga and Jonathan bring intense understanding and empathy to customers, as they feel compelled to fix this problem for them.
Moderne: Continuous Software Modernization
During the course of the next year and a half, we stayed in regular contact with Jonathan and Olga as the company was incorporated, the product was built, and design partner customers signed up. The feedback from the engineering leaders we introduced them to in large, enterprise companies was honestly pretty incredible and something we rarely see in tooling that early in its development. As we prepared this blog, we went back to our notes from some of those early calls, when the product was still in its infancy (it’s SOC2, Type 2 now and deployed at scale) just to ensure we weren’t having confirmation bias now!
And more importantly, the ROI that some enterprises using the early product were achieving was nothing short of magical. One dev team of 12 people was responsible for 420 source code repositories comprising 100s of millions of lines of code. They spoke about a framework migration that had been underway for over two years. Using Moderne, a single engineer was able to complete this migration in a day!
Of course, we loved the fact that the team was extremely careful to ensure there was no change to the developer’s day-to-day workflows. The Moderne platform simply plugs-in to existing build tooling and you’re off.
Pat Johnson, Director of Product Marketing at Moderne, wrote a wonderful overview of Continuous Software Modernization that we’d encourage you to read. It clearly outlines the use cases, how the tooling compares to code scan and search tools, and provides clear, actionable updates and migrations to start with. It also provides a glimpse into the Lossless Sematic Tree, which is a unique data model that underpins the ability to do highly performant search and – most importantly – repeatable, automation-driven refactoring and remediation at scale with minimal developer disruption.
Moderne’s platform supports Java and is quickly extending support for additional languages like COBOL (released in December 2022), Python, TypeScript, and C#. In addition to being SOC 2, Type 2 certified, the team is working on additional capabilities to operationalize continuous software modernization at scale. These include change campaign management, a recommendation service, a CLI to drive the local developer experience, and integrations with CI tools, IDEs, and other tools in the ecosystem.
Today, we’re thrilled to announce leading Moderne’s $15M Series A round, together with our friends at True Ventures, Mango Capital, and Allstate Strategic Investors. This problem is too big to not be solved.
