Agile methods are designed to cope with changing or vague requirements, and posit that big design up-front (BDUF) is wasteful, as the shifting requirements will make the design obsolete. Too often though, analysis and requirements gathering are lumped together with BDUF and the baby gets thrown out with the bathwater.

Certain requirements can be captured early, and indeed, should be captured as early as possible. Ironically, these are often the requirements that receive the least attention – the so-called non-functional requirements. These include such things as low maintenance, responsiveness, reliability, ease of upgrade etc. Sometimes the non-functional requirements can turn out to be the most important ones. For example, if a project is designed to replace an existing system that is always breaking, then the most important requirement from the point of view of the CTO / key sponsor may be that it is easy and cheap to maintain. Problem is, sometimes the non-functional requirements are so obvious to the customer that they forget to tell the delivery team. This is what requirements analysis aims to address.

Finally, on the subject of changing requirements, how many projects really start out as stock trading applications and turn into an air traffic control system?

Its all about differentiating the real requirements from the (to the business) incidental details.

For tonight’s XtC:

• Short methods
• Classes with personality – do one job well
• Minimise duplication
• Clearly express intent
• Test algorithms not implementation
• Code to interfaces
• Law of Demeter / Tell Don’t Ask
• Methods that return values should be idempotent
• Demarcate functional individuality with interfaces
• Understand the big picture – what problem are you trying to solve?

View image

At the risk of appearing to backpedal I’m going to point at Tim’s response to my ‘project death’ post, and then claim that what he said is what I meant 🙂

Project cancellation is just one manifestation of reality impinging itself on a project, albeit an extreme one. Reality biting is the generalisation of the specific example I was using.

Definitely an improvement, thanks Tim.

This idea is worth pursuing. Where do we go from here?

FingerWorks make what looks like the ultimate in geek input devices.

Found via The Recalcitrant Engineer: Reality Interactive are working on what they are calling a simulation container, written in Java. One of their first showcases will apparently be an implementation of the Quake engine. Nice.

So I was in the supermarket queue yesterday buying my lunch, not really thinking about much, and randomly sampling the conversations around me, as you do. Except that I can never really think about nothing. Every sentence or phrase around me was causing my thoughts to cascade and spin off in every direction, either forming an opinion about the subject, picking apart logical errors, or linking the topics mentioned with similar experiences of my own. Sometimes the price you pay for being blessed with lots of thoughts is that of having lots of thoughts, when all you want to do is eat pizza.

Tim Bacon has started a blog. Cool.

The agile development community has a number of guiding principles, such as ‘people over process’ and ‘values over practices’, that try to capture the essence of what it means to be Agile. I’m feeling contentious today, so I’m going to poke at them a bit, and also propose a single core concept by which I think Agility can be measured.

I (and I suspect most people) first encountered agile development in the form of XP. XP got the whole agile conversation started because it was so bold, and made no apologies for being so. For that alone the software community should be thankful.

However, the clarity of XP’s message has since been diluted by the whole Agile movement, and the debates over what it means to be agile, what was agile, and what wasn’t, how do you know if you’re agile etc. etc. and we all kind of missed the point.

The point is this: Agility is (from the dictionary) ‘characterised by quickness, lightness, and ease of movement; nimble.’

Another way of saying that is ‘responsive to change’. What is the single largest change that can affect any software project?

Death.

Any project can potentially be canceled at any point. Less severely, budgets and schedules can be slashed, or teams dissolved. Any one of a whole range of events can occur, but the result is always a change.

So, if being Agile means responding to (and more importantly) coping with change, and death is the single largest change that can happen to any project, shouldn’t an Agile process have a clearly defined mechanism for coping with it?

Yes.

You may cry, “Thats nonsense, this fool thinks you can survive death.”

Not survive, cope. In commercial terms, that means delivering the greatest business value in the face of change. In this case, in the face of unforseen project death.

Can you see where this is going yet?

Now we come to the big revelation. How do you deliver value from a cancelled project? By being ready to ship whatever work you’ve done at any point throughout the project. Ship, as in release, deliver, wrap in clingfilm and stick on the shelves. Not only that, but what is delivered should contain the most business value that was possible to achieve in the time you had.

I submit that this ability to deliver what you’ve got at any time is the single defining characteristic for Agility in software development. Every other practice, value, and position statement can be evaluated in terms of its relationship to this fundamental concept.

Glad we got that straightened out.

Arguments over software patents are highly topical at the moment (see this thread), so I couldn’t resist jumping in.

Software is about ideas. The act of writing code is that of expressing an idea in a way a computer can understand. Software patents appear to be an attempt to take ideas and thoughts and say, “This thought is mine. Nobody else is allowed to think it.” Its nonsense. For one there is the philosophical argument that there is no such thing as original thought (ie. every thought a person has is influenced by those they’ve come into contact with, and thus cannot be claimed as ‘original’). For another, most software patents are based on work that has gone before, which raises the whole issue of ‘prior art’, and what qualifies as prior art. The current furore over O/R mapping is a case in point. Thousands of developers all over the world have written ad-hoc O/R mapping code. It is such a universal problem domain that for one company or individual to claim ‘I invented O/R mapping’ is laughable. Its perfectly reasonable to try and come up with the best O/R mapping product, but perfectly unreasonable to claim that your way is the only way.

The only truly fair and equitable solution is to compete solely on the basis of quality of service, and for everyone to be honest and respect each other’s work, but what are the chances of that?

[ Previous post mysteriously vanished – for those expecting a post titled ‘O/R Patterns’ – it was just the following link. ]

Word of the day from the pseudodictionary:

narapoia – That uneasy feeling that you are unintentionally following someone.