Hi. My name is Charlie and I am an Engineer.

I have been an Engineer all of my life. I have written thousands of lines of code in dozens of languages, some of which you have never heard of.

I have worked with and managed teams of engineers from around the world. Some were just out of school. Others were Journeymen engineers with many projects under their belts. And others were “experts”. Some even have Turing awards!

Across this broad range of experience, there are some things that I have learned about engineers that are universal. One of those is that engineers like to make things work. They get great satisfaction from solving a problem and seeing the results in action. Anything that helps them reach that working result faster makes them happy.

Conversely, anything that gets in the way of getting to a working result annoys and frustrates an engineer. Bugs are high on that list of issues that annoy and frustrate engineers. As engineers, we all accept that we are not perfect and that bugs are part of the process. But anything that helps eliminate bugs and the time we spend chasing them is valued.

Which brings us to tools.

In general, engineers have welcomed tools that improve their productivity: computer languages that make code reusability simpler, IDE’s that speed the writing of code and finding simple errors early in the development cycle and debuggers that speed up the testing of code have all been welcomed.

And then there is static analysis or SAST (Static Application Security Testing).

Static analysis testing is distinct from Dynamic Testing in that the tool parses all of the source code in a project and builds a model of the program. That model is then analyzed for bugs. The good news is that, unlike dynamic testing, the developer is not burdened with creating the test cases to check for problems. Dynamic testing can often fail to uncover a problem because the developer “forgot to write a test for that”.

The bad news is that static analysis is working from a model of the program which, theoretically, has a nearly unbounded number of possible paths. So, while bounding the number of possible interpretations of the code, the tools typically produce lots of false positives. The providers of SAST tools do not want to miss a bug so they tend to error on the side of too many warnings.

As a result, engineers really dislike (can I say hate) using SAST tools. Most use them because their development processes require them to use them. The people in charge know that finding bugs early in the cycle and finding critical bugs saves them in the long run. But, if the engineers could choose, they would avoid them.

On the other hand, a SAST tool that could find the critical bugs without so much noise would be welcomed. Or, so we believe at OpenRefactory.

As engineers ourselves, we wanted to benefit from the potential advantages that a SAST approach could produce. But we did not want to suffer the overhead and tedium of processing false positives.

On top of that, we knew that, once we had a solid based of detected bugs, we could use advanced code refactoring technology to provide corrections for the bugs. So, on top of detecting bugs with much better precision, we could save developers even more time by also providing accurate fixes.

I think that Intelligent Code Repair, which implements all of this, will be a tool that will keep engineers happy. And happy engineers are productive engineers.