Blog

Flexibility, design and process

Software is, in theory, infinitely flexible. I can take the software from my toaster and, with enough modification, get it to run a nuclear power station. OK, I’d have to be pretty odd to want to do this, and one could argue whether it is the same software (does it pass the Mary Rose test?*) but you get my point.

(*The Mary Rose Test, the Mary Rose, is a wooden battleship from Henry VIII’s navy that is preserved in Portsmouth. Imagine I decide to renovate the ship, so every day I replace one of the aging planks of wood with an identical replacement. Now, further imagine that I use the planks I remove to build a copy of the Mary Rose. When I am finished which is the original? And at one point, if any, did it change?)

Much of software design is concerned with removing your flexibility: encapsulation, data hiding, cohesion. Sometimes you actually improve things by removing the option. (Less is more.)

The same is true in development processes. Often a company cries, “We need a flexible development process” because… we need to respond to anything a customer can throw at us, all our projects are different, etc. But I wonder how many of the organizations that say this actually do vary their process? In my experience companies like to say this but the only real variation that occurs is the number of people on the project. The actual project process is left vague and ill defined “for flexibility.”

If there really is no similarity in the projects that organizations do then I wonder if the organization really exists for a particular reason. What is the core competency if no two projects are the like? Far more likely there is similarity in some way.

So, what we need is to cut off some options to ourselves. I’m not saying we need to document our process – heaven forbid! Nor am I saying that we need to call in process experts to advice us on how to do the project. What I’m saying is we need some kind of process base line we can talk about, some reference point. For if we can’t talk about it we can’t describe it and can’t modify it. Within that we need to give ourselves some constraint, leaving all our options open makes for too much uncertainty.

With all that said its important to note that process must come from the bottom up. It is for the people who live and breath the process to decide what they are doing. That doesn’t mean they can’t be influenced in their decisions, nor does it mean they can’t be lead or challenged to do better. It may just boil down to showing them that things can be different and providing them with the tools and options to do it differently.

And when they find a better way of doing things the people above them should use their leadership to support it, and to help others see the benefits and change too.

The worst thing we can do is to just assume that tomorrow will be a repeat of today. We should ask teams to do better, to change, to improve but we should also give ourselves boundaries and rules to work within. And we should, from time to time, question those boundaries and rules.

Blog entry 1: What do I hope to achieve by Blogging?

As some people know I’ve not been particularly keen on blogging, so, since this is a blog, indeed my blog, that raises the question: Why?

In a future entry I’ll write about why I don’t like the word why but for now lets rewrite the question: What do I hope to achieve by writing a blog?

Well, I first got thinking about blogging about 18 months ago when I was at XTC (Extreme Tuesday Club) when Chris Matts asked “Do you blog?”

So, I’ve spent 18 months thinking about this and now I have a need. For about 5 or 6 years now I’ve been writing magazine pieces. Mainly these have appeared in ACCU Overload. They started with technical pieces and moved through an enquiry phase and into a research based new paradigm phase (influenced by my MBA course). Lately have become more opinion pieces.

After six years its time I tried something new, a forum that is more opinion based may just be what I’m looking for.

Next I’m quite taken with the idea of personal journals, or diaries if you prefer, or learning diaries if you want to give them a longer title. My interest in these was started when I kept one as part of my MBA course. Since then I’ve kept a professional diary quite regularly. I use it as a sense making and thinking mechanism in work.

I’ve always said that the advantage of a private diary over a public blog is that I can say things privately that I can’t say publicly, e.g. my boss is ??? However, I’ve also noticed a tendency in my own diary to sometimes become a frustration vent that can be less than constructive. So, this blog is an experiment: What advantages does a public blog have? Well, I’m about to find out.

(I suppose a legitimate question is: what makes me think that anyone would want to read my ramblings? Well my website is now taking over 10,000 hits a month so maybe some people are interested in my views.)

So now I blog. This is Entry One.

What is this blog to be about?

I’ve been politically active in the past but I’m not any more so I don’t think this will be a political blog.

There will be lots of software development stuff in here, that’s my background, although its something I’m trying to get away from – I’ll write another entry about this and identity sometime. When I write about software development I’ll probably be writing about Agile development and Lean software, I’m a big fan of both of these.

There will be some business stuff – I’m interested in business so I’ll pull that in.

Now there is an intersection here. Two in fact.

The first is Change. This is the real problem that both software developers and businesses face. How do I change my development team to Agile practices? How do my customers need to change? How must my business change?

Second, there will be a lot of stuff about Patterns. I came to patterns through software development (you know, Gang-of-four stuff) but my current interest is in applying pattern techniques to the business domain. When I say “business patterns” I don’t mean the kind of “IT business patterns” that some people propose as “business patterns” – I mean IT free patterns of business strategy, operations, etc. Take a look at my business patterns page if you want to know more.

There you have it, another blog is born.