Adam Kolawa and the business of fewer mistakes

In 2004, Adam Kolawa was running a software company with 250 employees around the world. About 150 worked in Southern California. Parasoft had never taken outside funding. Asked why, its co-founder acknowledged that building a company this way was harder. He preferred the freedom it bought him. There was work he wanted to do, and arranging his departure from the business was a peculiar place to begin.

“Don't start thinking about an exit strategy when you start out,” he advised aspiring entrepreneurs. His priorities were a product people wanted and the ability to sell it. For a founder in the business of reducing mistakes, this was an appropriately practical ambition. The glamorous part of entrepreneurship could wait while somebody established whether the thing was useful.

That preference gives his career its shape. Kolawa moved from Poland to California, from theoretical physics into commercial software, and from parallel computing into tools for improving how people wrote code. Across those changes, he kept returning to the arrangements around the work: how a team coordinates, how an error gets noticed, and who takes responsibility for fixing the conditions that allowed it.

A physicist leaves the laboratory

Kolawa came to the United States from Poland in 1983 to pursue a doctorate at the California Institute of Technology. He already had master's degrees in electrical engineering from AGH and physics from Jagiellonian University. Caltech's alumni record places his Ph.D. in the class of 1986. His route into business ran through a research environment where computing was part of the scientific work itself.

At Caltech, he worked with Geoffrey Fox on hypercube parallel computing. His research publications included work on the performance of hypercube machines and on dynamic load balancing. Those subjects dealt with getting useful work from cooperating processors. Years later, cooperation among people would occupy a considerable share of his attention.

In 1987, Kolawa and four friends from Caltech founded Parasoft. The company's early focus was parallel processing. It subsequently moved into software development tools and then into software quality solutions and services. The founder had crossed into a different market, carrying a researcher's interest in how systems behave when their parts have to work together.

The bug before the bug report

By June 2003, Kolawa was taking a three-year effort onto the JavaOne stage: Parasoft's Automated Error Prevention offering for Java applications. Its premise was to bring prevention into development, where mistakes were being made. Coding standards, static analysis, unit testing, regression testing, source control, and nightly builds belonged in a connected process.

The breadth mattered. A team could own several capable tools and still struggle to use them together. Kolawa's offering included services to help organizations introduce the practices into their existing work. He objected to products becoming “shelfware,” a word that captures the peculiar achievement of buying something sophisticated enough to gather dust expensively.

This was also a business proposition. Customers needed results from what they purchased. The appeal of an error prevention system depended on whether people could make it part of ordinary development. A tool that nobody used would have difficulty preventing anything except the renewal of its own contract.

Quality has a social life

Kolawa's 2005 prescription for improving software quality began with group culture. He wanted developers to take ownership of their code, cooperate with colleagues, learn from peers, and show mutual respect. He objected to arrangements in which programmers assumed a separate quality assurance department would somehow add quality afterward.

His other foundations were source control and automatic builds. Code needed a shared home and clear rules for handling changes. Builds needed to start clean, integrate the work, and run tests. These were repeatable actions that made errors visible while a team still had time to respond.

Some of his prescriptions were distinctly severe. He argued against allowing two developers to modify the same file simultaneously and distrusted automatic merging. The specificity is revealing: Kolawa was prepared to argue about the settings and habits that other discussions of quality might skip. A shared commitment meant making decisions about how people actually worked on Tuesday afternoon.

A contract is a poor substitute for understanding

His writing about outsourcing approached the same problem from another direction. A manager could believe instructions were perfectly clear and discover, near delivery, that the supplier had understood something else. By then, rewriting the work could consume the savings that outsourcing was supposed to produce.

Kolawa recommended direct language, written requirements, and a particularly useful return journey: have the supplier restate those requirements in their own words. He also wanted prototypes, whether sketches or simple programs, so both sides could examine what they were agreeing to build.

There is an unromantic courtesy in that procedure. A polite nod stops being evidence of comprehension. Each side has to expose its assumptions early enough for the other to correct them. The software problem begins in a conversation, well before a compiler has anything to complain about. His advice made that conversation part of the engineering work.

The classroom gets a working example

In 2003, California State University, Fullerton received Parasoft Automated Error Prevention software valued at $1.5 million. The gift supported its computer science department and a proposed online master's program in software engineering. Kolawa served on the degree's advisory board. Students were to encounter current tools and methods as part of their training.

Dorota Huizinga, then acting associate dean of the College of Engineering and Computer Science, welcomed the fit with the curriculum. She and Kolawa later co-authored Automated Defect Prevention: Best Practices in Software Management, published in 2007. The academic connection became a sustained collaboration on how to organize development.

Their approach described infrastructure that could automate repetitive tasks, collect project data, and support processes defined by people. The distinction left judgment with the team while giving routine work a dependable mechanism. In another expression of support for education, Caltech recorded a 2007 pledge by Elzbieta and Adam Kolawa to endow a graduate fellowship. His university ties continued well beyond graduation.

The buyer still has to think

A product demonstration in 2006 left software developer and author Yakov Fain impressed by Kolawa's ambition. Fain had spent half an hour with him and saw a suite aimed at the way managers organized development. He also emphasized that customers had to use the software properly. Purchasing the tools did not settle the management question.

That qualification suited the work Kolawa was advocating. Automation depended on decisions about what a team expected, what it would check, and what it would do when a check failed. The buyer remained involved. Even an enthusiastic account of the demonstration came back to the customer's responsibility.

Kolawa carried this argument onto conference stages. His May 2007 VSLive! Orlando session, Automate Infrastructure to Improve Your Dev Processes, addressed bringing requirements, development, and verification into a common infrastructure. The subject had expanded beyond the programmer at a keyboard to include everyone whose work determined what the software should become.

A television factory enters the argument

By 2009, Kolawa was speaking directly to senior managers through The Next Leap in Productivity. The book argued for applying quality management ideas associated with Deming and Juran to software development, then using improvements in IT to improve the wider enterprise. Its intended audience reached beyond the people responsible for writing programs.

In an interview that February, he compared software improvement with the accumulated changes that make a television production line more efficient. “It takes a lot of incremental steps,” he said. His insistence was on the accumulation: repeated improvements to a process, carried through over time.

He also made an arresting claim about Parasoft's own SOAtest 6.0: 34 people, 18 months, and 5.5 million lines of code. Those were his reported figures, offered to illustrate his productivity argument. They are a claim about one project, rather than a universal measure of developer performance. The ambition was clear enough: reduce the effort lost to work that a better process could avoid.

“It takes a lot of incremental steps.”

Adam Kolawa, 2009

The phone call after the argument

Kolawa brought strong feelings to the business. Editor Alan Zeichick, who knew him for more than a decade, remembered disagreements over coverage that Kolawa thought treated Parasoft unfairly or overlooked it. These could produce word that the founder was angry. A short telephone conversation generally restored the relationship.

Zeichick also remembered warmth and humor. Visits to the Pasadena office became part of his journeys through Southern California. Kolawa invited him to contribute the foreword and cover blurb for Bulletproofing Web Applications, which Kolawa co-authored with Wendell Hicken and Cynthia Dunlop. An editor and a founder could disagree about coverage and still enjoy each other's company.

The combination makes the portrait more interesting than a list of titles. Kolawa defended the work fiercely, but the friendship had room to continue after an argument. The person asking software teams to cooperate was himself capable of returning to the conversation.

The work that stayed

In 2001, Kolawa received the Los Angeles Ernst & Young Entrepreneur of the Year award in the software category. His technical work also reached the patent record. A 1999 patent naming him and three colleagues described automatically checking source code quality against rules. It made an engineering mechanism out of the wish to catch troublesome patterns consistently.

Kolawa died in April 2011. His wife, Elizabeth Kolawa, joined Parasoft that year and became its CEO. The company continues to develop automated testing products, including Jtest, SOAtest, and tools for C and C++. The business that began among Caltech friends has retained software quality as its central concern.

His career leaves a useful question for anyone who builds things with other people: how much of today's work is repairing yesterday's avoidable confusion? He pursued it through products, books, university partnerships, and arguments. There is little glamour in a mistake that never reaches a customer. For Kolawa, that was a perfectly good reason to build a business around it.