Replacing Humans with Software Inspectors

An anonymous reader writes "What if you were able to perform a portion of your code reviews automatically? In this first article of the new series 'Automation for the People', development automation expert Paul Duvall begins with a look at automated inspectors like CheckStyle, JavaNCSS, and CPD. The piece examines how these tools enhance the development process and when you should use them." From the article: "Every time a team member commits modifications to a version control repository, the code has changed. But how did it change? Was the modified code the victim of a copy-and-paste job? Did the complexity increase? The only way to know is to run a software inspector at every check-in. Moreover, receiving feedback on each of the risks discussed thus far on a continuous basis is one sure-fire way to keep a code base's health in check automatically!"

Comments

"way to keep a code base's health in check"

[Anonymous Coward]

from the article:

...way to keep a code base's health in check...

Uhhhh, maybe you should try an english language cliche parser instead?

Just don't get lazy

[just_another_sean]

I would say that, like any other code generator, wizard, druid, whatever you want to call it, this has a great potential to help with programming. As long as developers using it don't get lazy about checking their own code.

As a tool to point out obvious code flaws, catch conflicting code in large projects, etc. this is great. But I've found over the years that if you don't understand how to do something manually and aren't able to second guess a tool when it makes a mistake then these types of things can end up being more trouble then they're worth.

Just my $.02

Re:Just don't get lazy

[JeanBaptiste]

I view these things kind of like the 'grammar checker' in Word. Yeah, kind of useful once in a while maybe, but its not going to help you if you _dont_ know what you are doing, and its probably not going to be of any use if you _do_ know what you are doing.

Re:Just don't get lazy

[bunions]

So which are you - the guy who didn't know he was supposed to put an apostrophe in "don't" or the guy who did? Seems like either way, a grammar checker might have helped.

My point isn't that you made a typo and that you should feel bad, it's that everyone makes mistakes, including people who know what they're doing. That is why tools like this are useful.

The only way

[phantomfive]

The only way to know is to run a software inspector at every check-in.

Or you can hire people who are good and who you trust. A real human will do a better job of 'code reviewing' every time, and if you hire good people, then you don't need to worry about what they commit. An occasional check should be enough to make sure you haven't accidentally hired a loser. (Also human code reviews, if done correctly, are great because they help everyone become better programmers).

This is easy to do in small companies, but somewhat harder in big companies. Still, if I were CEO, and my managers started using this tool, I would get worried and start thinking seriously about how to change the company culture. You don't want your company to become like Qualcomm, or Novell, where bureaucracy rules the day.

Re:The only way

[tcopeland]

> Still, if I were CEO, and my managers started using this tool,
> I would get worried and start thinking seriously about
> how to change the company culture.

I'm not sure that using static analysis tools are a sign of a bad corporate culture. I think they're just one more safety net you can use to find code problems. This is especially true for something like CPD, which finds duplicated code anywhere in the codebase - checking for this sort of thing manually is pretty difficult.

That said, I agree that the Slashdot title of "Replacing humans..." is pretty inflammatory. But the dW article itself says it in a much more effective way: "Free yourself from mundane, manual inspections with software inspectors".

Re:The only way

[bunions]

"Or you can hire people who are good and who you trust. "

Or you could do both!

Automated QA tools are cheap insurance against mistakes, and I'm surprised by the resistance to them I see in these comments. No, of course no one likes out-of-control bureaucracy, but that's not an argument against using automated tools to check your code.

Oh, good, the silver bullet at last

[dpbsmith]

We've experienced those brief and tempestuous infatuations with flowcharts, Warnier-Ott diagrams, top-down programming, structured programming, Jackson structured programming, source code control, the waterfall model, Royce's Final Model, the spiral model, the sashimi model, object-oriented programming, CASE tools, Rational Unified Process, SEI's Capability Maturity Model for Software, SEI's CMMI, feature points, function points, agile methodologies, and Extreme Programming, and... well... they were just trips to the moon on gossamer wings.

But this. This is different. Totally different. It's the real thing this time.

Be smart

[Mock]

The thing to remember about automated code inspectors is: be smart about it.

Don't trust the code inspector to enforce a policy (except maybe coding style).

There's a lot of boilerplate code that goes into a program, and a code duplication monitor will cause all sorts of headaches in this area.

The same problem exists with comment checkers. If code is written properly, there is usually very little need to comment inside most methods. The name and javadoc will give more than enough description of what the method will do (you DO use javadoc, don't you?)
It's only as the method's complexity increases to a point where it's not blatantly obvious what's going on inside that you need comments at that level.

I've had too many managers force me to comment like this:

// Iterate over all files
for(Iterator iter = files.iterator(); iter.hasNext(); /* nothing to do here */)
{ // Get the next file
        File file = (File)iter.next(); // If the file has a modification date later than now
        if(file.lastModified() > new Date().getTime())
        { // Throw an exception stating that the file is modified in the future
                throw new ModifiedInFutureException(file.toString() " + has a modification date in the future");
        }
}


Ok it looks much uglier after running through Slashdot's dumb filter, but you get the idea.

The above code in reality needs no comments whatsoever, except perhaps a single line at the top saying "Disallow modification dates in the future", but a bad policy caused ALL code checked in to comply with silly regulations, resulting in countless hours lost.

In truth, the date check code itself should have been implemented as a policy class to be added to the verify method, but I digress.