Popped over to our local Java Users Group (JUG) meeting to hear a talk on Dependency Structure Matrix also known as Design Structure Matrix by a company called Lattix. Never heard of it, well neither have I.

The basic idea is it statically analyzes your project and maps dependencies between layers, or more accurately between packages. You can go in and define those layers and work with its simple model to sort of refactor the coupling out of your application. You can also add rules on what coupling is allowed and then run a quick report to see the exceptions. On top of that you can add rules around dependencies on external packages such that the only the DAO layer can use Hibernate packages for example.

Nice to see these sorts of developments as this can be added to your build process as another check, and it makes visible the dangers of coupling unrelated layers. Better to catch coupling early rather than later. The cost is $500 $495 for 500 classes or less, $1000 $695 for 1000 classes, and $3000 for the typical unlimited Enterprise license. I may add it to my todo list for looking into tools at some point. The only other tool that seems to do something like this that I was aware of before was Mike Clark’s JDepend, but I never had time to look into it much.

Kane Mar wrote recently about the difficulty teams have adjusting to finishing within an iteration:

Typically what this means is that the software will be code complete at the end of an iteration, but will not have been fully tested.

A comment that was frequently heard during the early retrospectives was that code was delivered late to the testers; usually just a day or two before the end of the iteration.

Over a year into our official Agile (PM/Excecutive sponsored) rollout this has continued to be our biggest common struggle. Keeping our QA staff busy on Agile projects often involves writing a few test cases up front and then slamming in the testing in the last 3-4 days of a 30 day Sprint.

The current mitigating ideas are:

• Actually use an acceptance test tool like Fitnesse to give testers work to do defining and writing acceptance tests.
• Break up functional deliveries to smaller pieces of functionality.
• Just do the testing for the last Sprint in the current Sprint.
• Writing GUI based regression tests on the past Sprint’s functionality.

We’re just rolling out Fitnesse on one project now so that strategy remains to be tested.

On the idea of delivering smaller pieces of functionality, we keep running into two roadblocks. One, is that on many projects we’re splitting development between web based OO software and legacy mainframe development. On the mainframe side they have been pretty consistent in sticking to a delivery in line with the end of the Sprint. So far no progress in getting that habit to change. Second, developers see a nice time box of 30 days and they want to fill it up with coding, not figure out how to deliver small bits of functionality that can be tested individually. We’re getting better at this, but often the argument is well I want to finish all of some module before I turn it over to QA and on the QA side they don’t want to ‘retest’. This has been getting better with practice though.

Kicking testing over to the next Sprint is pretty much an admission of defeat, but on one particular Agile project which involves a lot of parallel mainframe development the argument just comes up each Sprint that we should just throw in the towel and test the last Sprint’s code in the current Sprint. The dangers of this are numerous and we haven’t done it yet, but it’s a common refrain in retrospectives.

Finally, we have the idea of keeping QA utilized during the Sprint better by having them write automated regression tests. This is probably one of the better ideas, but we haven’t been able to implement it all that widely. The other issue is if the GUI is going to change significantly with new functionality the QA group often argues that they don’t want to write a lot of tests they’ll have to scrap and rewrite.

No clear best solution yet, but it is an area we’ve really struggled with.

This week I have 3 standups a day:

• 9:15am Scrum Master on a Proof of Concept project.
• 9:30am Chicken on an internal project.
• 9:45am Chicken on a large systems project in another building.

The disadvantage is I’m running around a lot. The advantage is I get a view into every project on my team every day.

I hadn’t quite grokked symbols in ruby for some reason. Somehow the definition from the PickAxe book wasn’t quite clear enough:

A Ruby symbol is an identifier corresponding to a string of characters, often a name.

OK, I can see that but what’s the point. Then playing around on Why’s 15 minute browser intro to ruby on the ruby language site I came across this definition:

When you place a colon in front of a simple word, you get a symbol. Symbols are cheaper than strings (in terms of computer memory.) If you use a word over and over in your program, use a symbol. Rather than having thousands of copies of that word in memory, the computer will store the symbol only once.

I like Why’s explanation of the why to use a symbol.

Simon Baker posted some pictures of his tracking white board. He actually has a velocity column on the far right end that occurs to me is a really good idea. Puts a visible focus on how much your actually able to accomplish for the Sprint instead of just the remaining hours for tasks.