Vincent Massol Think Tank

Clirr rocks!

[ vmassol ] 15:22, Saturday, 30 April 2005

Clirr is one of these tools that would deserve to be known better. I have mentioned it several times in other posts but it's really the first time I get to use it in real. It rocks! I'm about to release Cargo 0.5 and I wanted to get an exact list of the API modifications we have done compared to version 0.4.

Here's the kind of output Clirr gives (the full output is available here):

ERROR: 8001: org.codehaus.cargo.deployment.DefaultJarArchive: Class org.codehaus.cargo.deployment.DefaultJarArchive removed
INFO: 8000: org.codehaus.cargo.module.DefaultJarArchive: Class org.codehaus.cargo.module.DefaultJarArchive added
ERROR: 7002: org.codehaus.cargo.container.Container: Method 'public void addDeployable(org.codehaus.cargo.container.deployable.Deployable)' has been removed
INFO: 7011: org.codehaus.cargo.ant.ConfigurationElement: Method 'public void addConfiguredEar(org.codehaus.cargo.ant.EARElement)' has been added
INFO: 4000: org.codehaus.cargo.container.jetty.JettyStandaloneConfiguration: Added org.codehaus.cargo.container.configuration.StandaloneConfiguration to the set of implemented interfaces
ERROR: 7005: org.codehaus.cargo.container.Container: Parameter 1 of 'public void setConfiguration(org.codehaus.cargo.container.Configuration)' has changed its type to org.codehaus.cargo.container.configuration.Configuration
ERROR: 7006: org.codehaus.cargo.ant.ConfigurationElement: Return type of method 'public org.codehaus.cargo.container.Configuration createConfiguration(org.codehaus.cargo.container.Container)' has been changed to org.codehaus.cargo.container.configuration.Configuration
ERROR: 4001: org.codehaus.cargo.container.jetty.JettyStandaloneConfiguration: Removed org.codehaus.cargo.container.Configuration from the set of implemented interfaces
INFO: 7003: org.codehaus.cargo.container.spi.AbstractConfiguration: Method 'public void configure()' has been removed, but an inherited definition exists.
ERROR: 5001: org.codehaus.cargo.container.deployable.EAR: Removed org.codehaus.cargo.util.MonitoredObject from the list of superclasses
INFO: 5000: org.codehaus.cargo.container.deployable.EAR: Added org.codehaus.cargo.util.monitor.MonitoredObject to the list of superclasses
ERROR: 7012: org.codehaus.cargo.container.Container: Method 'public java.io.File getOutput()' has been added to an interface
INFO: 7010: org.codehaus.cargo.container.spi.AbstractContainer: Accessibility of method 'protected java.io.File getOutput()' has been increased from protected to public
INFO: 6000: org.codehaus.cargo.container.property.GeneralPropertySet: Added public field JVMARGS

Even though we're using JIRA with an Iteration-Driven Development strategy (IDD) it was still a very interesting exercise to verify that we had not missed any issue by running Clirr on the source code. In addition, it provides a more detailed view of what exactly has changed in term of API which our JIRA report does not provide.

The next step would be to use it to fail our build whenever someone introduces a public API break. It would be quite easy for us because we've cleanly separated non-public API from public APIs by using internal packages (see the Cactus API design rule to see what it means). Of course sometimes, you want to voluntariy add a breaking change. That's legitimate but it has to be controlled. The strategy would be to have the build fail and then if the change is voluntary to exclude it from Clirr.

Well done Lars!

TrackBack

> Vincent, you talk about IDD using JIRA wich consists of entering every
> development task which have an impact on user before implementing it. I've
> found a post from you on this subject
> (http://www.xwiki.org/pipermail/developers/2005-April/000241.html) but
> can't manage to find any more detailed material.

There's also some information here (but not more details I fear): http://blogs.codehaus.org/people/vmassol/archives/000905_6_jira_issuesmells.html

> I'm used to follow this
> practice which can quickly begin developement centric and can be subtle
> (How do you affect task to pair programmers ?

First I've never done pair-programming so I won't know from experience but I don't see what it would change. The pair is to be considered as one person, right? The only thing that it would change is the velocity and thus the ability to have more cards/stories/issues per iteration I think.

> is IDD like XP planning game

Yes. Planning game is the strategy. IDD is one embodiment of it using an iteration-friendly issue tracker. It's just a fancy name I've made up... :-)

> ? What do you answer to master Ron Jeffries when he advice you to use
> simple card ;-) ?).

Sure, that's a good advice. The cards are physical and as such probably carry more weight (in both sense of the term) for assignees. However, I work in environments where I have distributed teams (onsite and offshore) and physical cards are not very handy even though Fedex/UPS are very fast ;-)

> Finally, my question is : do you know any good article
> on the subject or do you plan to write one ?

I don't think I have enough meat for a full article just yet but maybe. IDD is being followed by more and more open source projects. It doesn't need a proper planning game but it's the same philosophy and for business projects it's absolutely crucial to have this planning game to define priorities, needs, etc. For OSS projects it's less a necessity as tasks are implemented on a itch-to-scratch basis.... :-)

--VincentMassol, May 2, 2005 01:47 PM

> IDD it's just a fancy name I've made up... :-)

Perhaps, but a name was missing to identify this practice and you 've brought it ;-). You've given two acronym definitions: Issue Driven Development and Iteration Driven Development. IMHO Issue Driven Development suits well as iterative is a more general agile notion.

> The pair is to be considered as one person, right?

In front of the computer for sure, but in the tracker system it's not so obvious. As pairs are encouraged to split as often as possible (in a week) I can have pair 'Marcel-Robert' for issue-1, pair 'Marcel-Paul' for issue-2 and 'Vincent-Robert' for issue-3. So in our case we affect issue to two programmers and each one can follow/manage his issues in his own tracker tray.

In IDD approach:

- we also encourage developpers to give and enter an estimation for each issue before beginning to code. Not to stress them or blame them if estimation is not correct but to continuously improve team estimation capability.

- each user story (planning game) is an issue and each technical task required to complete the user story is a sub-task. So we can easely check if user story estimation is in sync with technical tasks estimation sum and easely estimate user story completion based on technical tasks completion.

- having to enter a issue in the tracker system and so its description constrain both developers and project leader to correctly understand what they are talking about

Moreover as you say:

- everything that is meant to be developed is visible to everyone on the
project's issue tracker

- when a release is performed, the user change log is automatically
generated by the issue tracker tool. Thus nothing is "forgotten" in the
release notes.

- users participate to the development by submitting ideas to the issue
tracker and even better, attach patches to issues.

- a single system, making it easy to get the status of the next version.
This requires to create versions and attach the issues to those versions.

so IDD is being followed by more and more open source projects but not in so many business projects (at least in France and in Switzerland). A lot of compagny use tracker system to follow bugs but not to manage projets. Perhaps the acronym IDD was just missing... ;-)

--Freddy Mallet, May 2, 2005 11:02 PM