A single number representing whether you’re six months worth of coding is actually not crap. Not code coverage, Checkstyle warnings or defects per thousand lines of code but a single score.

Alberto Savio of Agitar Software presented on his new Crap4J tool at an Agile Open California session this week. Crap4J produces a single number defined by the following equation:

CRAP(m) = comp(m)^2 (1 - cov(m)/100)^3 + comp(m)

m = method
comp(m) = Cyclometric complexity of method m.
cov(m) = Test code coverage for method m.

In written terms:

Complexity bad. Tests good.

Right now there’s just an Eclipse plugin to try it out. Anything with a Crap number of 30 or above is a crappy method. And any project with more than 5% crappy methods is a crappy project. Alberto explained they wanted it to be an Agile metric so that it actually got used out there and part of that was keeping it simple. The other factor is it can easily be adjusted based on feedback and running it against many codebases.

What if you have a CRAP codebase? You can attempt to game the number to bring down the number of crappy methods. And how do you do that? You just write more tests against the high CRAP methods. And then it starts to occur to you that you could refactor as well. Gaming the system is writing tests plus refactoring. You can focus on a single number and encourage good behavior.

Assumption was soon after installing the developer tools for Mac OS X 1.5 Leopard I’d have a brand new spanking copy of Java 1.6 on my MacBook Pro.

$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

OK, surely it’s just defaulting there. Nope, no 1.6 version. No problem it’s supposed to be on the Apple Developer web site. I’ll just have to download it. Turns out there’s no mention of 1.6 at all. There’s the 64 bit support for 1.5 on Leopard, but no mention of 1.6. And there’s plenty of historical references to the Apple Developer site having downloads of Java 1.6 in the past, they’ve just pulled them all off the web site.

OK, we’re still not using 1.5 at work yet, but it would be nice to run 1.6 at home.

Dave Nicholette argued recently that Enterprise Architecture and Agile are not compatible partners:

The mission, scope, tools, mentality, culture, and personality types of enterprise architects and agilists are so radically different that (in my view) they call for separate administrative subdivisions in the enterprise. Not only is the nature of their work different, but the management styles, employment incentives, and career path options that work with one group don’t work with the other. The staid working conditions and deliberate pace of progress of enterprise architecture work would bore and frustrate an agilist. Conversely, the intensity and unpredictability of agile development would stress out the type of person who tends to prefer things standardized and repeatable.

I’m taking a little different tack on the meshing of Enterprise Architecture and Agile. Enterprise Architecture is a holistic attempt to define systems, processes, and tools across the entire organization though much of the focus ends up on the IT functions. Agile is a process within this and as it facilities better projects and faster ROI it lines up well with the goal of Enterprise Architecture. The central goal of Enterprise Architecture is to simplify IT.

Architecture within an Agile project is continuously evolved, but with the end goal that it should remain as flexible as possible while delivering at each iteration. You want the system to be as lean as possible, you shouldn’t be writing speculative code that might be used in the future.

Traditional ‘Ivory Tower’ style Enterprise Architecture does clash with Agile as it assumes a command and control culture with a heavy focus on governance. I see no reason Enterprise Architecture can’t be done in an Agile fashion. Even analyst firms like Gartner agree that defining a future architecture and then sticking it on a shelf never to be revisited is a recipe for failure. My belief is Enterprise Architecture efforts are only going to be successful through collaboration with developers, testers, business analysts, PMs/Scrum Masters, and business customers. And the critical cycle of ‘inspect and adapt’ on Agile projects is just as crucial to Enterprise Architecture.

My suspicion is with Agile and Lean ‘crossing the chasm’ lately we’re likely to see big changes in the approaches to Enterprise Architecture in many shops.

I’m off to my first open space conference later this month at Open Agile California. Should be a great chance to recharge some batteries and talk about issues with sustaining agile. I know after three years of Agile and two years of our official effort that we no longer do a lot of questioning and looking outward for new ideas. I’m focused on how you re-energize an organization at this phase, especially when many of the original high level sponsors of the effort have moved on.

As the consequence of a reorganization I have a lengthy new title at work:

Manager of Enterprise Architecture and Governance

I’m no longer a software development manager building up a team and delivering projects. In the near term I need to develop a charter, hire at least one new architect, and get started on some basic foundational work such as coming up with as-is and to-be models of our architecture.

I have some plans for how to be an effective enterprise architect team:

• Concentrate on people. Mentoring, training, and guiding people will help you implement the right architecture.
• Plan big, small steps every day. Incremental is the way to get there.
• Governance disagreements should be rare.
• The business needs to trust you. Confidence building takes gobs of time, but if you can’t keep convince your business customers, you can’t make the big changes.
• Architects must code. No one gets to step back and just spend all their time in UML and Powerpoint. Everyone has to spend some time on real projects implementing their ideas and getting direct feedback on how well things work.

Nothing like defining a new role from scratch to get me out of bed in the morning.