Behind the patent: A 'natural' way to detect root causes of software defects

By: Siddalinga Aradhya, Rajesh Ganji and Abdul Kareem Lakkundi 

Nature can teach us some valuable lessons about software development.

For example, today’s software and applications contain millions of lines of code written by different people or companies over time. Modifying or removing even a single piece of critical code—much like changing or eliminating a single element within an ecosystem—can disrupt the performance and integration of various software applications across IT environments.

The parallels between natural habitats and software systems remained top of mind as we developed US11698829,¹ a recently patented method (known informally as the ‘829 patent) to identify root causes of software defects.

While we’re certainly not suggesting our invention is on par with nature restoring order to an altered ecosystem, the method described in the ‘829 patent may one day fundamentally change the way developers and engineers detect and correct defects in almost any type of software—like the kind that powers dashboards in cars and processes transactions for banks.

How the ‘829 patent works

Root cause analysis has been used in software development for decades.² It’s a proven way to test, identify and address the underlying causes of software defects rather than focusing on symptoms like error messages or system glitches.

The process outlined in the ‘829 patent takes root cause analysis to another level.

By temporarily replacing a line of software key code with a substitute line of program code—which we’ve dubbed a hedge code—the ‘829 patent methodology creates a temporary software failure. The fabricated defect produces error logs and graphs for the hedge code that engineers can trace back to a software feature, allowing programmers to map root causes of any errors experienced along the way.

In an ideal scenario, software engineers could deploy the process described in the ‘829 patent to test millions of lines of software code and compile a comprehensive database of hedge code-induced errors and related root causes. This data could then be used for predictive analytics or targeted troubleshooting to identify root causes of software defects in near real time.

Here’s another way to think about the invention. Many homeowners use hedges as natural fences to keep things out of—or in—their yards. People and animals can move freely on both sides of these boundaries, but motion is limited within and between different hedges. Essentially, that’s what the ‘829 patent process allows programmers to do.

Engineers can use the method described in the ‘829 patent to build a temporary barrier akin to a lawn hedge (hence, the name) around a small section of source code. Programmers are free to create disruptions and study the results within the protected area and establish hedges at any point in the software environment, enabling them to run extensive testing throughout the system without harming areas outside the hedge.

Benefits of the ‘829 patent

Time and money. The method detailed in the ‘829 patent may one day help companies save substantially more of both.

Allowing engineers to study root causes of software defects at their own pace and under controlled conditions provides valuable real-world training—without having to wait for an actual failure to occur. Plus, inducing a temporary failure lets programmers test and learn about software environments while avoiding costly disruptions and extended downtime.

For instance, if software designers used the method described in the ‘829 patent to proactively test software and create detailed data records, they could reference their findings when a customer encounters a software issue. By examining your customer’s error logs and comparing them to data tables created during dry runs with the method specified in the ‘829 patent, your team would be able to quickly pinpoint the source of the software defect, dramatically reducing mean time to repair (MTTR).

With the process described in the ‘829 patent, engineers may also be able to decrease the amount of regression testing when developing new versions of software. They could run the hedge code and compare error codes with the previously mapped data logs to ensure the new software code is addressing defects at the proper location.

Simply put, the methodology documented in the ‘829 patent is designed to reduce or eliminate guesswork in software development and streamline the entire root cause identification and correction process. Better performing software, in turn, can help boost productivity, improve efficiency and increase savings throughout an organization.

Potential use cases for the ‘829 patent

Since the method outlined in the ‘829 patent can be applied to any type of software, there are scores of potential applications in virtually every industry. A few include:

• Automotive applications. Newer vehicles are equipped with software that controls everything from the engine and transmission to the heating and air system and most in-dash components. Software companies serving the automotive sector could potentially use the methodology described in the ‘829 patent to develop software and upgrades that are more reliable and better suited than older technology for the sophisticated electronic systems in late-model cars and trucks.
  
  Over time, using the process of the ‘829 patent to refine software development could help reduce many quality issues and factory recalls associated with faulty or poor-performing software, saving automobile manufacturers time and money while increasing satisfaction among dealers and end users. Potential applications of the ‘829 patent methodology could increase exponentially as edge computing and the Internet of Things (IoT) enable greater connectivity in automobiles and electric and autonomous vehicles become more mainstream.³
  
  
• Financial services applications. Within the financial services industry, the technique described in the ‘829 patent may eventually play a key role in modifying data protection practices for banks, credit card companies and other organizations.
  
  For instance, developers could substitute program code with hedge code in software upgrades to help financial institutions recalculate recovery point objectives (RPOs). These new insights could then be used to update data backup protocols for financial transactions, customer relationship management (CRM) databases and other sensitive records, providing an added layer of protection when organizations experience anything from minor service disruptions to major data events.

In time, software developers may also find use cases for the ‘829 patent methodology in the health care, retail, manufacturing and government sectors.

A final thought on the ‘829 patent

On the surface, purposely triggering failures in software environments may seem at odds with developing the most reliable and efficient applications and systems possible.

However, for designers who experiment with the method described in the ‘829 patent to understand the interplay of disparate lines of code scattered across software ecosystems, the invention may evolve into an essential element of modern software development.  

Siddalinga Aradhya is Associate Director for Software Architecture, Rajesh Ganji is Senior Lead for Software Engineering in Quality Assurance, and Abdul Kareem Lakkundi is Product Manager for Kyndryl Orchestration Software Product Management.

¹ Identifying root causes of software defects, Google Patents, 2023

² What is root cause analysis? A proactive approach to change management, CIO, May 2022

³ Corporate business building to unlock value in automotive connectivity, McKinsey & Company, August 2023