(This blog entry is part of a series of entries describing some of the new features in Code Collaborator v6.0. The series content is listed in this entry.)
Even though we sell a peer code review tool, we're not so arrogant as to believe that tools alone make teams more productive or solve software development problems. It's people that actually write software - not any tool. And if there is a problem with a software development process, it's the people that have to solve it; if there is an opportunity to improve the process, it's the people that have to seize that opportunity.
Tools like Code Collaborator remove friction and grunt work from the process in order to help people create bug free software sooner (among other benefits).
One of the most interesting parts of working here is that we spend significant time talking to people about how they create software. We use those conversations to guide the obvious things on the product road map (which version control systems to support, etc.) and also to guide the process-oriented features in the product.
And the most important process-oriented feature is: Code Collaborator does not enforce any particular type of process. I don't even think the word "process" is in our owner's manual. The tool does provide a basic work flow, but it can be tuned significantly in order to meet your needs.
With v6.0 of Code Collaborator, we have added two new tuning features to help an administrator control the social effects of peer code review:
1. Customizing the Word for "Defect" allows you to control what our user interface displays:
In Code Collaborator, a "defect" is anything that has been found during a review that in order to resolve it, you will need to make a change to the file(s) being reviewed. So that's not just algorithmic bugs in the code but anything that requires a change: a missing comment, an unclear comment, an opportunity to refactor, an opportunity to use a different API, etc.
But as the old saying goes, "People are only human," and in some environments the word "defect" has a very negative connotation. We've had customers report to us that users of Code Collaborator were hesitant to enter "defects" into the tool because they thought it would make the author of the code being reviewed "look bad."
Instead, the defects get entered as comments, which is better than not having them entered at all, but comments are not as easy to track (each defect, on the other hand, is assigned an ID, etc.). This is really a communication issue (more on that topic here), but configuring the tool can help.
So with this enhancement, if a team is more comfortable with the term "Item," or "Finding," or "Entry," or whatever, then they can use that alternate word. Here at Smart Bear, we use the word "Booger."
2. Suppressing the Commit Action Items will remove confusion in environments where committing to a version control server must be done a certain way. Back in Code Collaborator v5.0, we added a feature that will actually commit your code changes at the conclusion of a pre-commit review. After all, the Code Collaborator client tools know how to access your version control server and they know which files were reviewed.
This commit does not, however, happen automatically. So to provide a reminder Code Collaborator creates an Action Item for the author at the conclusion of a pre-commit review:
The problem is that in some environments, the administrators of the version control server do not want the commit done other than with their specific tool/process. So displaying that reminder was confusing because users were tempted to use Code Collaborator for the commit.
Disabling the creation of that Action Item is done via a new entry in the General settings: