“Cogito ergo sum.” — Rene Descartes, 17th century French philosopher and mathematician.

To me, software processes are a kind of intelligence, and that means to me that every program is alive. This is how I really see it.” — Benjamin Shapiro, founder of Thinking Software.

You’ll get the connection soon. But first…

Long story short, Shapiro, a teenaged student at an engineering military academy in St. Petersburg, Russia, had a math professor suggest he look into Boolean algebra. He went on to do some work in the computer department, where he published “Formula of Algorithm.” After deciding not to graduate as a military officer, and spending time “banished to a very cold place,” Shapiro got his diploma from a technical institute before migrating to the United States in 1979.

By 1981, he was building a debugging package based on his “Formula of Algorithm,” working in Fortran and then COBOL. The debugging package morphed into a dynamic code analyzer, which is implemented in his Software Understanding Machine. The goal is to ensure business-critical software is reliable. From this work, and with his brother, Roman (who came from Russia in 1990), the company Thinking Software was founded in 1995.

(Related: Why machine learning is the new AI)

“I had a contract with Google, and I showed this work to their director of R&D Peter Norvig—he’s a very famous guy in artificial intelligence—and I told him what we built is different because we don’t work on data, we work on cause/effect, which makes us faster and much more efficient and secure,” Shapiro recalled. “We don’t expose people’s data. He liked it and pushed the idea of doing a proof of concept project with Google. Two years later, we had proof of concept.

“We then moved to work on the Java language,” he continued. “One of the questions at that time, by another director, was how are you going to deal with race conditions? I went home and then realized this is not a missionary technology like a Software Understanding Machine, but it’s a well-known issue, and it was in addition to what we do in SUM. By the way, SUM happened to be a good acronym, because ‘Cogito ergo sum,’ by Descartes, means, ‘I think, therefore, I am.’ I really liked this combination, because the Software Understanding Machine understands cause/effect and propagates knowledge. It’s knowledge deduction.”

From all of this has come Race Catcher, the company’s flagship product for ensuring software reliability. Race Catcher does dynamic analysis of code to find and understand contentions within the code. These race conditions are a well-known issue in software, but are not so easily defined. As Shapiro put it, “Stack Overflow has about 12,000 questions about what race condition is, and each question has several answers. I checked a year later, and there were 13,000 questions.”

The most common definition is that race conditions occur when multiple application threads are accessing memory, and one thread alters the memory being used by another, rendering the application unreliable. Static analysis tools cannot analyze everything and return too many false positive and false negative results, Shapiro said. Dynamic tools give results as they happen, but he said they usually come with large overhead.

Shapiro explained how Race Catcher works. “The first element of the Software Understanding Machine is the user interface. Some user interface builds models of software in order for a programmer to understand what the issue is. The second element is Race Catcher. It analyzes executable code, which means we don’t need source code. But the programmer, of course, needs to see source code to understand the issue. So when our product locates issues automatically during program execution, since Race Catcher is dynamic code analysis, as opposed to static analysis, issues have to be explained to programmers, and we do this automatically by dragging the issue onto the model of the code we built automatically, which comes from the Software Understanding Machine.”

A third element is what Shapiro calls ARM-CM: Application Reliability Management via Collaborating Machines. He calculates that approximately 1 billion virtual machines are in service today, with the overwhelming majority running Java. ARM-CM allows multiple Race Catcher instances to become part of a local network—what he described as “conscious machines running the same applications” and ensuring reliability through a social network machines that have “common interests” and create knowledge of the applications that are running.

In short, with Race Catcher, applications can automatically analyze themselves. They think, therefore, they are.

About David Rubinstein

David Rubinstein is editor-in-chief of SD Times.