Michael Poulin wrote: > Not really answering Gregg's question, let me remind about JTest tool > from Parasoft. It allowed configuring a policy that controlled (up to > 500 policies) Java code righting style. For example, if any 'catch' > clause was left empty or if number of methods in the class was more than > specified, the tool generated compilation errors. > > This was direct developers' worry. This was explicit development time > governance. > > So, what "the wrong people are in charge of how that governance is > occurring" in my example?
Michael, what I am talking about, related to your example, is that there are specific cases where such things might actually not be a problem. Managers and executives always want to make judgment of applicability to the budget and/or success of a product using "numbers." It's the selection of which things to count that are typically where developers worry. Developers want to see things that actually matter across the board. For example, instead of using JTest as a tool for code quality analysis, I'd suggest FindBugs instead. And, what you should do, is have a system where you reach an agreeable set of "known" issues, and then your build environment should not allow additional "issues" to be added, which don't get investigated. But the build should not STOP, it should just identify and enumerate the new issues. That allows the developer to spend time on things that do matter "at that moment." For example, there are VCS/SCC systems that don't let you submit changes unless those changes meet formatting requirements, such as where braces are used. It's those kinds of road blocks that are silly. The editor should do that for you, so that you can change your work habits early, rather than creating a nightmare over 2 days work when you try and submit your code. Gregg Wonderly
