There’s a new version of Crap4j available. The big feature is Ant support via a new Crap4j Ant task.

This won’t mean as much if you are using the Eclipse plugin, but if you want to incorporate the Crap score into your regular build, or if you want more control over the classpath setup for your project, this will be a way to achieve it.

For the Eclipse users, you can just update the existing version via the Update Manager.

For the Ant version, there is a different distribution (sometime soon I will make it one download.) You can get the zip file at http://www.crap4j.org/downloads/crap4j_ant_latest.jar.

See the full usage instructions on the Ant Usage Page.

We hope you find it useful, and please let us know how it works for you.

Mike Slinn suggests annotations to exclude methods that you don’t want contributing to the Crap score. I think some form of exclusion is definitely a good idea. I am curious what type would work best.

I can think of at least 4 ways to get various levels of exclusion:

• Add annotations that can affect the method. (May also want these at the class level or beyond)
• For class-level exclusion, use the about-to-be-released Ant task, which can do file excludes and includes.
• Have an exclude list that takes patterns like ‘MyClass#myMethod(Ljava/lang/Object;):Void’
• Use different compilation output directories for classes that do not ship. This is the way many people manage their test suites.

I am thinking that annotations are the cleanest, at least for the method level. It seems like the approach chosen depends on how many exclusions one wants to do. The annotations could be spread all over the code and troublesome to maintain, but on the other hand they are great for a small number of exclusions.

What do you think? Any altogether different way to do it? If we went with annotations, what is a good name. I find Mike’s suggestions amusing.

Yesterday (October 29th) I gave my talk on crappy code at “The Business of Software” conference. Given the line up of other prestigious (and professional) speakers, the pressure was on but, apparently, the talk went quite well. Here’s what Bob Cramblitt had to say about it:

A Man Who Knows His Crap

Alberto Savoia of Agitar Software (www.agitar.com) knows crappy software, in every permutation. More than talking about it, his company is eradicating crappy software through better testing. Business of Software 2007 attendees were treated to a hilarious treatise on crappy software from Savoia. Those who experienced Alberto live won’t forget him anytime soon. For the rest of you, there’s the interview on this blog: http://blog.businessofsoftware.org/2007/09/alberto-savoia-.html

The talk was recorded on video-tape and I’ll try to get it posted on YouTube or on the crap4j.org website sometime soon.

After all the talks:

At the post-conference reception I had the opportunity to meet and talk CRAP with a bunch of interesting people. I met Scott Farquhar, one of the co-founders of Atlassian (a very cool and successful company doing work in software metrics) - it would be great to see the CRAP metric show up in their product.

At the end of the evening, I went to a (late) dinner with some of the other speakers and had an opportunity to meet spend some quality time talking about CRAP with Joel Spolsky and Eric Sink. After a full day of talking about software, I was actually more interested in talking to Joel about his cross-country bike trip, something I’d love to do myself one of these days. However, we ended up talking about the CRAP metric.

Joel is not a big fan of software metrics in general. He is concerned that developers might end up writing code and allocating their time to satisfy a specific metric rather than writing the best possible code and allocating the time based on more important criteria. He narrated a couple of stories about horrific metrics misuse that he witnessed first-hand and was concerned that - in the wrong hands - the CRAP metric could be used in, say, performance reviews: “You code is too crappy. You’re fired!”.

I understand that there is potential, as well as evidence, for software metrics misuse; but I don’t think that’s sufficient reason for avoiding metrics altogether. My reply to Joel was that if an organization/manager is so lazy and stupid to rely exclusively on any given code metric in evaluating programmers, then those programmers are probably better off being fired from that organization anyway. Better yet, the programmers would have great evidence to have the moronic manager fired.

While I understand that any tool, technology, or information can be abused by “evil” people and misused by stupid ones, I don’t think we should use “How could this be abused or misused?” as the primary criteria - at least not without first balancing the potential benefits.

Toward the end of the conversation, Eric Sink observed that the argument was starting to sound a lot like the perennial “Guns don’t kill people, people kill people” discussion. Great observation Eric.

On a more positive note, Joel did think that the CRAP metric could be useful when applied to existing code (i.e. post-facto) and said he might experiment with it.

I am not taking Joel’s concerns lightly; I respect his opinion and experience and I know that there are other people that feel as strongly as he does about software metrics. He has definitely given me something to think about - and blog about.

I met and talked with several other great software thinkers and practitioners besides Joel and Eric at this conference, and I will talk about them in future blogs.

In the meantime, thank you Joel and Eric for a stimulating late night debate. And Joel, the next time we meet let’s talk about biking cross-country before we start talking about software. All work and no play …

Alberto

Tomorrow I will be speaking at “The Business of Software” conference, along with some very well-known speakers like Guy Kawasaki and Joel Spolsky.The title of my talk is “Better Code: Recognizing, Avoiding, and Sanitizing Crappy Software”.I will be explaining the motivation and need for the CRAP metric and show-off Crap4j. So far most of the people who have been experimenting with Crap4J have been techies, tomorrow we’ll see how more business types respond to it. I’ll report back after the conference.Alberto

Jeff Fredrick sent a link to the wiki for CitCon where there is a discussion about a session entitled, Crap4J and other metric tools.It points to several other tools for checking your code as well.

Greetings. We have released a new dot version of crap4j! You can get it on the downloads page.

We have fixed some bugs, and cleaned up some other things in preparation for new features. In particular, we fixed a problem with duplicate results, and some cases where it didn’t return properly from systems that use annotations. Also, the icon and menu items (popup and menu bar) are now enabled properly, and only when it is a java project that is selected. That should prevent some confusion.

We appreciate everyone’s bug reports and feedback. Thank you and we hope the new version works even better for you! (If not, please let us know or file a bug.)

Yesterday I had the pleasure to attend my first “open format” conference: Agile Open California. I found the open format extremely interesting. Not having pre-determined speaker/topic schedule felt a bit strange at first, but I got over and jumped in with both feet by proposing a session on the CRAP metric.

The session was a lot of fun. I explained how we arrived at the current metric components (complexity and code coverage) why the formula is the way it is, and then demonstrated it on a couple of projects.

As usual, there was a lot of enthusiasm but also a lot of questions and suggestions for improvement. Most people, however, understood very well that this is an open and agile metric - which means that they can contribute to it and that it will change as we use it and discover ways to improve it.

My favorite part of the session was coming up with a “Me tarzan. You Jane” explanation of the metric:

“Complexity bad. Tests Good.”

Overall a great session. Here’s a link to unedited session notes (thank you John for taking them).

Alberto

So, here are some quick quotes from people on the web about Crap4j.

We’ll be adding in the references shortly. We didn’t make them up. Really!

“OUTSTANDING! and funny”

“I love the idea and I love the name!”

“Pretty good stuff. I ran it against of a couple of projects and it gave me about what I’d expect from them, so that’s great.”

“It produces some curious results though. On some occasions it even seems to imply my code could be improved…”

“We’ve just got to support this in Hackystat. JavaNCSS provides complexity, and we can combine that with Emma coverage.”

Professor Philip Johnson wrote about Crap4J in his blog. In addition having one of the best jobs I could think of (i.e. CS professor at the University of Hawaii), he runs the HackyStat project, a very well thought-out open source framework for automated collection and analysis of software engineering process and product metrics. Coincidentally, we started looking at HackyStat at the same time he started looking at Crap4J.

In his blog, Philip writes:

“Immediately after sending this link to the Hackystat Hackers, a few of us started playing with it. While the metric seems intuitively appealing (and requires one to use lots of bad puns when reporting on the results), its implementation as an Eclipse plugin is quite limiting.”

Yes, the Eclipse plug-in is quite limiting - especially if you don’t use Eclipse :-). But it looks like some HackyStat developers are going to take the metric, make it work with HackyStat, and spend some time studying it.

Dr. Johnson even hinted at a Master Thesis on the CRAP metric:

“Maybe I can get a student next semester to work on a crappy master’s thesis.”

Sounds like a great idea to me. I’d almost consider going back to school to work on it - especially if it’s in Hawaii.

Alberto

I just posted an entry on Crap4j in my blog on O’Reilly’s “Beautiful Code” website.

Here’s an excerpt from the blog entry’s introduction:

“If I had to write a tool that would attempt to decide if a particular piece of code could be considered beautiful, I would not know where to start. Detecting crappy code, however, seemed more within reach; so we threw caution to the wind and we gave it a shot. Read on and you can decide if that shot would have been better used on something else (like our foot).”

The original blog on Crap4j on Artima resulted in quite a few comments. I am curious to see if we get a similar reaction on Beautiful Code.

If interest in the C.R.A.P. metric and Crap4j continues to grow, we might write a companion book to Beautiful Code. Here’s an idea for the cover page inspired by the original:

Alberto