AK: No, definitely not. For a long time, I took this automation for granted. Since the early 1990s, our developers have been religious about leveraging automation to ensure that software is produced consistently and efficiently. We assumed that everyone else was like us, and designed our products to work in strict, highly-automated development environments such as our own. However, the more we visited our customers, the more we realized that we were wrong… and as a result, many of our customers were not getting the most out of the products they had purchased from us. You just can’t effectively implement unit testing, static analysis, and other best practices unless you have a solid, automated development infrastructure in place first.

 

It was disappointing to learn that automation really is not all that widespread across the industry. But the good news is that there’s a huge opportunity for the industry to really unlock the power of automation.

Java Developer’s Journal: As a book, what kind of longevity do you envisage for Automated Defect Prevention? Might it truly become your magnum opus, the crowning of a career of unrelenting devotion to the theme of best practices ­ - or, at the very least, better practices! ­ - in the management of software development? Could its value last for a decade?

 

AK: I can’t predict the future. I do know that I didn’t write it as a career-crowning achievement. I wrote it because I wanted to tell people that this opportunity to increase productivity by a factor of ten exists and can really be accomplished. For me, this is a very exciting message.  Once people catch on to this, this book might become irrelevant. If the book achieves my goal of helping increase productivity, I would welcome this irrelevance.

AK: The main thing that I take away from theoretical physics is the process of building a theoretical model, and never believing in its validity until you confirm that it really works. All my life I was guided by these principles. You take a roadmap and build a theoretical model, then you test it to see if it really works. As you get feedback from the experiments and applying the model in real life, you modify the model and drive it forward. That’s how I’ve always operated.

 

I have also taken some concepts from theoretical physics and converted them for computer science. For example, Parasoft Jtest’s automated unit test case generation is based on the perturbation theory from physics.

 

AK: I want Parasoft to grow and survive me. My goal is to develop as many people as possible that can take over the reigns and guide Parasoft into a successful future. This means I need to make Parasoft very strong in its current space, plus diversify it so it’s resilient. That’s what I’m working on now. Of course there are further towering peaks to climb, but I don’t want to jinx them by talking about them right now.