You Know It When You Visualise It

I didn't find out until afterwards that Erik Dörnenburg is one of the ThoughtWorks boys and girls we have working with us in Berlin at the moment. He's helping them to design a new API for our RESTful services. Now I like this kinda acronym soup anyway, but, for a front-end dev, on a day-to-day basis, I absolutely reply on these things being good (and having a jsonp interface, of course), so I like Erik. He's going to help the awesome back end folks upon whose shoulders we stand to be even more awesome.

So, Erik is going to tell us all about Software Quality - you know it when you see it.

He starts off by showing us a million different ways to gather data on our software quality and I tweet rather prematurely that...


"Software quality. You know it when you see it" seems to be about "you know it when you measure it in a million different ways #qcon

And yes. That is kinda the point. If you don't have the metrics, the data, how can you analyse it? If you don't know where you are starting from, how do you know how to get somewhere else?


Once you have the data, all of it - lines of code, number of modules, lines of code per module, number of classes (& modules per), complexity, dependencies, then you can start to do some cool stuff with it. 
2-dimensional visualisations - dependency structure matrixes for example, are rather cool and let you see where classes are doing too much, or are too important - but it's the 3d stuff that's cool.
Imagine one of those complexity charts where the size of the square illustrates the number of lines of code and the deepness of the colour, the complexity.
Now don't call it a square, call it a footprint of a towerblock and build the stories out of numbers of modules and colour them in according to number of dependencies. Or something else? Whatever metric you want to look at, use it and visualise your entire codebase in one 3-dimensionaly city. 
Compare this against revisions in SVN, and watch the buildings grow and swell and shrink and  change colour and you have a living representation of the way your code city has changed over time - maybe you will spot trends or identify weak spots. Or strengths.
Compare different parts of the codebase to spot outliers - overly important or reliant sections. 


The DIY method.

• Gather the data. Use free toold
• Aggregate the data. There are build in unix commands for much of this. Excel pivot tables are pretty handy.
• Render as graphics - again, use free tools. It is Erik's opinion that all commercial tools that he has seen offer nothing over and above the free stuff.

Ultimately, it gives you the confidence to say "Yes. We have written good code."