Static Analysis: Sooner rather than Later?
The other day we met with a new prospective alpha partner for our upcoming MSVS release (Visual Studio support is scheduled for July 2009). This customer has a lot of smarter people creating impressive code bases to challenging requirements.
Having presented how Goanna is different in that we fit within the IDE, as opposed to sitting with/behind the central build, I asked the question as to when and how they run peer reviews.
The response was that they use a minimum of 4 persons for each review, and so co-ordination and execution is a significant investment. Furthermore, developers will not typically call for this until they have “finished”.
By being available within the IDE during development, Goanna helps “smarter people find dumb mistakes” sooner (see Ansgar’s post below). Also there is additional benefit available on the optimisation of downstream processes; by taking this action sooner rather than later.
This is also reminded me of another case; where initial static analysis efforts had a QA team audit warnings after the nightly build and file bug reports when appropriate. This didn’t scale as it didn’t always get the reports to the right people at the right time, and who is best positioned to decide on the severity of a bug in the first instance?
Just to clarify though; I’m most certainly not advocating that you do not perform static analysis with/behind the central build, where modules are collated from the wider team.
My point is that Goanna has additional value add beyond assisting smarter people to find those dumb mistakes. The smarter people agreed and we look forward to working with them.