Tuesday, April 10, 2007

Look Mom, No versions.

Something that as troubled me a little, is the link between 'blue' OOP and Agile practices. I say 'troubled' because Agile development is widely misunderstood and I fear that 'blue' OOP is widely misunderstood for similar reasons. It is not widely acknowledged, but Agile development practices stem from OO programming practices and Smalltalk. Agile development breaks with the traditional idea that Software development can ever be deterministic. The desire for a deterministic software development process stems partially I believe from the desire for control. And the thing that non-Agile Managers want to control the most is change. We have all heard of the cost of change curve, where the cost of software change increases by a factor of ten, the later in the development process the change occurs. With a functional or procedural language this makes sense. Since everything is by default inter-connected, then any change is likely to propagate to other areas of the code. So the last thing you want to do is to 'allow change' once you have established a significant code base.

On the surface, this anti-change policy sounds like common sense. It even sounds similar to other common sense ideas like ' get it right first time', which seemingly promote an early determination of requirements and design upfront. But if you think about it, not allowing changes once you have code rules out maintenance, and also assumes that your customer knows exactly what he or she wants at the outset.

In practice it turns out that this 'big up front design' approach just doesn't work that well, and in fact exploring and experimenting in code, and allowing change to occur all the time can work much better. This is the philosophy behind dynamic languages, where feedback from experimentation can be gained relatively quickly. The problem though is that the 'embrace change' approach is counter to what most of us have been taught, and is not widely seen as 'industrial strength'.

The other thing about embracing change is that your code base needs to support change. The existence of unit tests and the 'safety' that they provide has been well documented in the Agile world. Tests do allow you to detect bugs introduced by changes, but it would be much better to avoid introducing bugs in the first place. This is where OOP and encapsulation comes in. If you can encapsulate your business logic inside objects that only communicate through loose messages, then the chances are that you will be able to introduce changes which remain encapsulated themselves and do not spread throughout your code. So OOP allows you to introduce changes cheaply, by reducing coupling through message sends and increasing cohesion through encapsulation. The biological metaphor of a cell which Alan Kay uses is a good one in this regard. Cells are independent and autonomous and go about their daily function independent of each other. The cell membrane provides encapsulation, so changes that occur within the membrane are localised and specific.

Using this technique people like Jeff Sutherland (Scrum) and Kent Beck (XP) realised that you could flatten the cost of change curve, and thus introduce changes at anytime during the project development life-cycle. This simple realisation opens up a number of new possibilities.

Gilad Bracha has a presentation where he takes this idea of allowing continuous change to it's logical extreme. Gilads idea is of bits that rot. Software that automatically updates itself continuously whilst running. In such a world version numbers have little meaning. The only version that counts is the latest. Without a fixed version your software is no longer an artifact, but a service consisting of a continuous stream of improvements and fixes. Old code rots away and is replaced by new code continuously. This idea fits well with a biological metaphor too.

Take a look at the presentation by Gilad. It is almost an hour, but is well worth watching.

2 comments:

Andrew said...

Hi Paul, Andy here.

I think that there are actually two differing ways of looking at the whole change control thing.

Development is - well development, not production, so any kind of predictive process is not a good thing. This is because we deal with a lot of unknowns and constantly changing parameters - not least the mind of your customer.

However, I think there is another side to this. Once your code makes it into a production environment, you do want everything to be deterministic, well controlled etc. because you don't want to interrupt service to your customers and threaten you SLA's.

Thoughts?

Paul said...

Hi Andrew,

The jury is still out for me. Have you watched Gilads' presentation? It is pretty convincing. The whole idea of the code changing underneath you whilst you are still using it is really novel.

I've got a few thoughts:

1. I like the idea of modelessness, where time never stops. So for example, over time you may completely change the interrior furnishings in your home without ever stopping and starting the server :^). Getting rid of the run/install modes for software is a good thing I think :^)

2. Backwards compatibility tends to hold back better ways of doing things sometimes. Accepting that code can always change under your feet, means that backwards compatibility is no longer such an issue. All your deployed applications will be using the latest libraries and APIs. The downside is that you will always be playing catch up, to ensure that your code works with the latest libraries.

3. The real issue is just how often will you be prompted by unsolicited changes. For example if Hibernate issues a new library update, do you really want to be forced to update all your dependent apps, run tests and re-deploy? Much of this could be automated, but it could still require a certain amount of manual intervention.

Your point about SLAs is a good one. Gilad comes from a Smalltalk background where changing code on the fly is common place. The bottom line is that this approach would have to work seamlessly. If it does, it could represent a significant change in how software is delivered. It would also bring new meaning to the idea of releasing early and often.

The way I see it, is that there isn't that large a leap from daily builds and daily releases to production as performed by some Agile teams and what Gilad is suggesting.

With the right level of automated integration, testing and releasing and with the right programming language support as Gilad suggests it should be possible.

It wouldn't work for all Apps, but it definately fits with the web model.