Agile Software Process Improvement

Ever-Decreasing Cycles - Draft Article

 

You can find a draft of an article I'm writing about the trend towards getting feedback about software quality ever faster and more cheaply. The end vision is one regular blog visitors might be familiar with - that of the continuous background tsting and code quality analysis I've spoken about in the past.

My argument is that, just as background compilation has freed our minds from the minutiae of syntactical correctness to allow us to focus on higher matters - like what the code acually does and how easy it will be to change - I foresee a time when continuous background unit testing and static analysis will free our minds from thinking about correctness and internal design quality to allows us to focus on even loftier issues like how easy the software is to use and whether we're delivering the most valuable features.

Well, a man can dream, can't he?

Video Conferencing

 

Remote collaboration can be fiddly stuff.

Right now I'm sitting in a client's videoconferencing suite in London staring at a huge LCD monitor showing a video feed from a similar room in Birmingham.

There's nobody there, of course. Despite all the marvels of modern communication technology, we still can't get folk to turn up meetings on time...

And I can't help noticing what looks like a bowl of sweets on the table at their end. I've just got tea cups and tea bags. No hot water. Just tea bags and tea cups.

They could have Skyped me at home. I've got chocolate biscuits and Lapsang Suchong. And - more importantly - water and a kettle!

Au Revoir, BBC. It's Been Great.

 

So today is my final regular day working with the good folk of BBC Worldwide, and as well as tying up a few loose ends - I find it's always a good idea to keep the final day or two of a gig free for loose ends - I'm also turning my mind to the dark road ahead and what the future might hold.

I have some outstanding client commitments to take care of this summer, and then - well, who knows? (I'm available for consulting and coaching, by the way - as well as weddings and Barmitzvahs.)

The 10 months I've spent at the BBC have been the most rewarding of my career. I'm probably as much transformed - especially in my values and my outlook - as they appear to be by the whole experience. I've always cared about software development, but now I think I care even more. And I especially care about helping people enter this great profession, and in encouraging those already in it to care as much as I do and to get actively involved in the wider software development community.

Whichever beach I wash up on next - and let's hope no well-meaning Greenpeace types try to drag me back out to sea - I know my focus will be on the underlying culture and on the people who do the actual work and the managers who support them. As a well-known war criminal once promised us: Education. Education. Education. But it's a different kind of education, and for that I have BBC Worldwide to thank.

I finally understand now that I'm not here to teach anybody anything. I'm hear to encourage them to learn and to share their knowledge. Lasting change comes from within, and as external consultants we must realise that no amount of training, coaching, bullying or pandering will ultimately lead to lasting progress. You can lead a horse to water, but you can't make it drink...

Maybe I'm being naive. Maybe my judgement is clouded by the fact that I like these folks so much. But I'm quietly confident about the future of software development at Worldwide. I think if it's going to happen anywhere, it's going to happen here.

Hopefully our relationship will continue in the background. There are some shared goals and some ongoing activities I'm sure we'll collaborate on. And I hope I'll get the chance to pop in and do a bit of rabble rousing from time to time, too. Whatever happens, I'll be keeping a very close eye on how things develop.

That said, it only remains for me to publicly thank everybody at BBC Worldwide for a fantastic 10 months. It would be wrong to try to name everybody, as I'm bound to accidentally leave people out. But I would like to especially thank Peter Camfield - my alter ego at Worldwide - and Gareth Charles, the guv'nor in development, for having a great vision and the nerve to support what we've been doing, even when I was really pissing him off. I'd also like to thank Kerry Jones for helping to bridge the gap between the developer communities in Worldwide and in BBC corporate. I hope that spirit of sharing and collaboration will grow. Certainly, there's much to offer from both sides.

I'd also like to thank Tamsyn Courtenay, without whom a whole bunch of stuff wouldn't have actually physically happened. It makes a massive difference when you have someone to find rooms, book refreshments, sort out projectors and do all that sort of stuff that - trivial as it may seem - can tie even the most organised consultants up for days at a time!

As for the rest of them - well, they know I love them all. Even the project managers! (But don't tell them I said that...)

Onwards and upwards!

Patrick Smacchia's Write-Up On Detecting Untested New/Changed Code

 

Patrick explains here with more authority than I could how to use new features in NDepend to weed out any untested code that's been added or changed since your last build.

Finding Untested New Or Changed Methods Using NDepend

 

NDepend users may be pleased to hear that they can indeed look for untested new or changed code. According to Patrick Smacchia:

Yes you can play with both comparison and test coverage.
Btw, we added a set of default rules/queries about that,
in Diff / Changes / Evolution -> Test Coverage of Changes Summary
and personally it is my favourites queries

...

// Method changed partially covered by tests
SELECT METHODS WHERE
PercentageCoverage < 100 AND PercentageCoverage > 0 AND
CodeWasChanged
ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered ,
NbLinesOfCodeNotCovered


// Method added partially covered by tests
SELECT METHODS WHERE
PercentageCoverage < 100 AND PercentageCoverage > 0 AND
WasAdded
ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered ,
NbLinesOfCodeNotCovered


// Method changed not covered at all
SELECT METHODS WHERE PercentageCoverage == 0 AND CodeWasChanged ORDER
BY NbLinesOfCode DESC


// Method added not covered at all
SELECT METHODS WHERE PercentageCoverage == 0 AND WasAdded ORDER BY
NbLinesOfCode DESC

Holistically Speaking...

 

Consider this: some of the most critical pieces of code in your organisation will only become apparant when you consider all of your software as a single, interconnected system.

Architects, take heed!

Identifying High Risk .NET Code With NDepend

 

That clever chappy who markets the .NET metrics tool NDepend has added a very useful feature. You can now import unit test coverage reports from NCover into a code analysis project, and compare test coverage with other bug-influencers like code complexity.

So you could, for exampe, write a code quality constraint that warns you if NDepend finds any methods that have low or no coverage and high cyclomatic complexity (along the lines of the CRAP4J tool). This might highlight methods that are likely to be buggy because:

a. There's more that could be wrong with the code, and

b. There's less chance of our tests detecting such defects

If you wanted to especially smart-arsed about it, you could also include method rank (the extent to which other methods directly or indirectly depend on a method) and pull off a report of methods that are:

i. Likely to be broken
ii. Unlikely to be known to be broken
iii. Likely to have a wider impact if it is broken

If someone were to ask me which methods to prioritise in improving test assurance, such a list might prove very enlightening.

There's also - and I haven't tried this yet, so maybe it can't be done in NDepend today - the tantalising possibility of measuring test coverage of new or changed code, since NDepend allows us to compare two versions of our assemblies. When you're working on legacy code, and you want to be sure that developers are being genuinely test-driven even though the overall coverage might not be improving much, this could be useful information to have to hand.

Agile Governance Game - Recap

 

If you've played a few rounds of the Governance Game, you might well have left wondering "yeah, and?"



There are a number of theories being tested by the game - and its variations. Some of them have already been explored on this blog in days of yore.

I thought it might be useful to gather together the main theories in one post for convenience, so here it is.

The aim of the Governance Game is chiefly to allow me to test a variety of management strategies in a simulated project (or portfolio of projects). The key question I've been asking through the game is how do we manage projects in the face of inescapable uncertainty?

Most project management texts I've seen have suffered from what I consider to be a delusion; namely that we can reduce or even eliminate uncertainty. I have - in the past - referred to this as reductionist or linear management. The reality I see every day is a world away from this. Not only can we not eliminate uncertainty, but our very efforts to do so are usually counterproductive.

Software development is a creative process. It's a sequence of innovations, and the thing about innovation is that it is inherently risky. If it's new, that means we've never done it before. If we've never done it before, we cannot know in advance what effort, cost or reward it might entail. If we have done it before, then that's not innovation. That's duplication of effort. (Or "copying".) In a 100% effective development process, whenever we hit problems we've already solved, we reuse the solutions. The rest of the time, we innovate. In practice, even very similar looking solutions can turn out to be markedly different when it comes to realizing them. The devil, as they say, is in the detail.

So the reality is that we're stuck with high levels of uncertainty because that's at the heart of the very nature of what we do. We innovate. And innovation is risky. There's no getting away from that.

But in real projects, we are often clouded by the sheer complexity of software development, and it can be hard to see how certain kinds of management approach help us to improve (or reduce) our chances of success. I was struck by how, in many branches of science these days, simple games and simulations were being used to explore often incomprehensibly complex problems - like earthquakes and stock market fluctuations. Could it be that something as frighteningly complex as software development could be distilled down to a simple game, where a couple of dice played the part of "that which is beyond our control"?

The purpose of the game is to allow us to explore the things we can control as managers, and get a feel for how they might help us to stack the deck in our favour. (I'm mixing metaphors quite liberally, here.)

A practical explanation of the game can be found here.

Strategy #1 - Prioritising

The basic game allows us to explore prioritisation strategies. Even though we cannot control the dice, we can control the order in which we play the moves around the board. Simulations across millions of games suggest very strongly that the best strategy is to start with the most valuable, least risky moves.



If we plotted a graph of each planned move with the risk on the X-axis and the reward on the Y-axis, we would want to start with moves in the top-left of the graph (high reward, low risk) and work our way down to the bottom-right corner (high risk, low reward). Proiritising these "low-hanging fruit" can very significantly improve our chances of delivering more value in a project with limited time and resources.

Strategy #2 - Iterating

In a variation of the basic game, teams plan and execute their routes around the board 20 dice throws at a time, effectively giving them 5 iterations and 4 opportunities to come up with a better plan. Iterative and incremental delivery is an absolute must-have strategy in any sufficiently complex process. Many would argue you need to iterate because the nature of the problem you're trying solve (e.g. the business landscape that your software will operate in) might be changing rapidly, and you therefore need frequent opportunities to adapt your plan. Actually, to be frank, most business landscapes are so ill-defined that it's impossible to know if they're actually changing. And, in fact, it doesn't matter if they aren't. It's not the fact that they might be changing that should concern us, is that fact that they are so complex that forces us to iterate our solutions.

In comparison to many software solutions, a grid of 12x12 squares is actually very simple. And yet, even there, there are actually many millions of possible routes around the board, each offering a different set of odds of scoring a certain amount of points. What are the chances that first route we choose will be the optimimum solution? Vanishingly small. After playing a few moves, it's quite likely that you'll spot a better route. Iterating allows us to learn and our solutions to evolve. Evolution is a very successful natural search algorithm, proven to work in solving very complex design optimisation problems.

Strategy #3 - Capability & Resourcing

In another variation, teams can select which kind of dice to use in each iteration. This allows them to manipulate the odds of, say, throwing a 6 or a 10 or whatever numbers might be required by that segment of their plan. Throwing a 4 with two four-sided dice is significantly easier than throwing a 4 with two 12-sided dice, for example. But the best dice are in limited supply (remind you of anything?), and in observing this variation of the game, I almost always see teams timing the start of iterations to improve their chances of getting better dice. They also collect intelligence on which teams have the dice they want, and how long it might be before they'll be finished with them. If your plan would work best with two four-sided dice, for example, and you see that another team has the dice you want, but they will be handing them back in a few minutes, you might choose to wait. But if they have literally just started their current iteration, you might choose to compromise (e.g., two 6-sided dice).

Again, simulations very striongly suggest that there is a useful strategy here - in knowing when to wait for the right people and when to compromise. I have rarely seen real development organisations strike that balance, though. I think we tend to compromise far too quickly, and end up hampered with less productive teams in the long term, to the detriment of our projects. Speaking from experience, it can also be to the detriment of the better developers. If being available to start work on Monday outweighs your ability as a developer in hiring decisions then there's little incentive to learn and improve.

Strategy #4 - Backing Winners, Shooting Losers

The last variation I want to discuss here concerns managing multiple teams. A new role is introduced into the game, called the guv'nor. The teams play as before, but the guv'nor now allocates dice throws in each iteration to the teams he or she feels will give the best return (in terms of points scored). There are still 20 dice throws for each team in the game, but the guv'nor can choose to give all of them to a single team and force the other teams to sit out that iteration, for example. So if there are 5 teams, the guv'nor must allocate 5 x 20 throws among them in each iteration. The guv'nor also gets to decide when iterations start and end. Beyond that, they are not allowed to interfere in the individual teams' games, and have no visibility other than the scores of each team and the number of dice throws they used.

Now that we've established that there actually are strategies that can be applied, and that there is therefore some skill involved, we get to explore the kinds of decisions that we normally associate with executive governance.

Again, simulations across large numbers of games strongly suggests that the skill here is to allocate more resources to higher-performing teams. Teams that are falling behind significantly should be starved of resources. There are, of course, time pressures that prevent the guv'nor from allocating all the dice throws to a single team, so in this variation of the game the brutality of the fuinding decisions is limited by the constraint that you must allow the time to actually plan and execute each short iteration.

How unlike the real world, though, where projects that fall behind are - often for entirely political reasons - given more resources to try and get them back on track. The reality is that this rarely works. Adding more developers to a late project will usually make it later because of the learning curve and the exponentially rising communication overhead associated with larger teams. I've seen resources diverted from projects that were actually doing quite well to try and prop up failing projects, which is the exact opposite of what should be happening.



There are more variations that I've toyed with, and I can think of even more that I've never gotten around to trying yet. But I hope you can get a sense from this little write-up that, even in the face of inescapable uncertainty, there are strategies we could apply that will improve our chances.

Dr Who Series Finale Thank You

 

For any who happen to stray on to this blog, here's a thank you if you made it to yesterday's Dr Who Series 4 Finale Party in Clerkenwell, London.

And for those of you who were unable to make it, here's a slice of the cake.



Hope to see you at the Xmas shindig!

The World Has Finally Gone Mad

 

And here's the proof...

Apparantly an 8-year-old boy has been reported to the government by his school in Sweden for violating the human rights of two of his classmates.

His crime? He didn't invite them to his birthday party.