Version 1.1.5 of Crap4j is available at http://www.crap4j.org/downloads/.

It has some bug fixes, and a really exciting new feature or two.

The big feature is that you can share your CRAP results anonymously (or publicly) and see how you fare against all the other projects uploaded. It even puts the global average in the report graphic to make it more useful. (You can turn this off if it’s just too painful

You can see stats on other projects on the benchmark site.

We hope that this will help us understand the CRAP metric better in the wild, and that it will provide users an opportunity to check themselves against fellow developers.

Enjoy, and please let us know how you like it.

Well not quite a movie, but I’ve created a 6 min video showing the basic usage of Crap4J:

1) Run Crap4J

2) Identify crappy methods

3) Add tests or refactor crappy methods until you have eliminated them

The video quality is not very good due to YouTube’s compression, but it should help people get the basic idea of how to use Crap4j.

Here’s the link to YouTube: Crap4J Basic Demo.

Alberto

I just realized, via the netrenderer service, that our site looks pretty bad in IE 6 and IE 5, and that 10% of our visitors used those browsers. Yikes! I’ll be putting up a graceful degrade in the near future, but in the meantime, if you can, you might want to upgrade to IE 7. It seems like it has been out for over a year now!

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