Stephen Freeman Rotating Header Image

February, 2009:

An "optimistic" view

Yesterday morning on the the Today programme, James Lovelock said that he was feeling quite optimistic because he now thinks that the Earth will still be able to support 1 billion people by the end of the century—as against nearly 7 billion now.

Sometimes the current financial crunch feels like a dry run for the bigger show.

"Broken gets fixed; shoddy is forever"

…which is why maintaining quality is so important.

From Hillary Johnson at Agile Open Northwest

"He doesn't mean that about Scrum"

In very bad taste, but very funny: “Hitler’s Nightly build fails”.

and we should remember that Stalin won…

Experienced Agilista's proved wrong (again)

So, Jurgen Appelo is unhappy that some of the more experienced Agile names have been telling him what to do. In particular, apparently they’ve been doing so without understanding complexity theory; he’s not reacting well.

In between the ranting, much of what Jurgen says is obviously true. For disorganised teams, adopting Scrum and nothing else will help them get more organised and productive, as seems to be his case. But he then goes on to say that anyone who tries to clip his wings and tell him how to develop software cannot be agile because they’re not adaptive enough—and by the way, he knows lots of stuff about complex adaptive systems that other people don’t.

My first reaction is to suggest that he not underestimate some of the people he’s reacting to. Ron Jeffries can certainly be provocative, but I don’t think he does it to try to convince people he’s smart. And some of us have been investigating complex adaptive systems for years.

What I think Jurgen is missing (or at least not making explicit) is that there isn’t a single axis between chaos and ordered, some aspects of an organisation do need to be ordered (in the end, we’re dealing with physical machines here) and some things complex (the people bits, usually). I may use complex adaptive techniques to understand what to build and how to communicate that, but I also want the thing to work reliably and not to be dragged down by a fear of making changes.

Sure, people in the community say dumb things, but we have actually learned some things over the last ten years. One is that we see team after team that has hit the wall because they didn’t work cleanly. Some have the luxury of a financial buffer which allows them to continue working sub-optimally. Just a few teams have understood the real trade-offs and can undercut the opposition by delivering faster and more reliably—and no-one promised that it would be easy or quick to achieve.

We're not craftspeople yet.

Software Craftsmanship 2009

In the run up to Software Craftsmanship 2009 it’s worth reminding ourselves how far we have to go. Recently the (London) Times put the dire state of UK government IT projects on its front page.

One bright correspondent suggested:

Why not use university computer science departments for large public sector IT projects? They could form part of the course work and would be far cheaper as there would be no culture of profit to worry about.

I can just hear the other disciplines jumping on this bandwagon: “it was costing too much to do the stress calculations for our nuclear power station, so we assigned them as coursework”, “we can’t afford these QC’s, so we got some students to handle the negligence case”, and “accountants are expensive so we had some students work out the portfolio risk” (no, wait, that last one might make sense).

Anyway, as long as anyone is not too embarrassed to put this sort of nonsense in print, we don’t have a profession.

Lean and Agile: should cousins marry?

Dave West has written a cautionary posting (Lean and Agile: Marriage Made in Heaven or Oxymoron?) on the dangers of taking a simplistic view of Lean and Agile. He’s right that a naive reading of a Lean approach to software will just trap us in another metaphor, manufacturing, that’s as inappropriate (or appropriate) as we once thought building construction was. And yes, there will be teams that adopt the techniques without understanding the meaning behind them, just as we’ve seen with all the Agile methodologies. I particularly like his reminder to show the bigger picture by making visible the current product backlog, with all its inconsistencies and misunderstandings.

I think there is a place for the production features of Lean in software practice, such as the idea that when I get something working, it really works and it stays working. I think there’s value within development on staying focussed on the task at hand and getting in “Done, done”. For some teams, just getting their system to a state where they can safely make and deploy changes is a huge advance. As Martin Fowler points out, there are quite a few “Agile” teams that can’t achieve that. Working in a reliable code base where all the mechanical stuff just works is so much more productive than the alternative, which counts, I think, as removing waste.

David Anderson claims that nowadays the most significant waste is usually around development rather than within it. It’s in the weakness of the organisation’s communication and prioritisation, the stuff that Dave has pointed out we need to support; teams waste effort when they don’t communicate and understand.

Once I started exploring deeper into the Lean material, I discovered the Toyota Product Development System which some think is even more important than their Production system. From a Production point of view, it looks very wasteful because they work on multiple possible solutions but choose only one, which allows them always to deliver on time. From a Product point of view it’s worth the cost because slipping the date is too expensive, and it’s not totally waste because they record what they’ve learned from the failures and use it the next generation of products. I think this is where much of the activity that Dave wants to remind us about belongs, and many software teams just don’t spend enough on exploring the range of features and technical issues available to them.

To mangle Dave’s metaphor, I don’t think we should expect wedding bells because the couple is already too closely related. There will be mistakes of interpretation in the field, such as dismissing retrospectives as waste, but, properly understood, the underlying values share too much DNA.

SOLID Development Principles – In Motivational Pictures

Excellent series of images from Derick Bailey. Here’s an example:

Single Responsibility Principle

Just because you can, doesn’t mean you should.

SingleResponsibilityPrinciple

RT @Jtf

Sic transit gloria mundi

Apple have declared the 12″ G4 PowerBook obsolete. If you can be bothered, you might notice that the document is dated December 2008, but the news has only recently attracted attention, in my case via The Register.

This is something of a blow. Our venerable PowerBooks are still very useful, although my wife’s has lost its optical drive (probably because she dropped it hard enough to buckle the case). For all its faults (like rubbish wireless), it’s still one of those laptops that every technical generation just hits the spot. Around 2000, it seemed like everyone I knew was buying a Sony Vaio 505; it was exactly the right weight and felt very solid to use.

So, now we’re on borrowed time. Apple don’t make a laptop which I can open properly when travelling coach, or just pop into whatever bag I happen to be carrying. There must be an alternative

From an interview with Terry Pratchett

“Why have you got six screens? Because I haven’t got enough room for eight.”

BBC Documentary, “Living with Alzheimer’s”