Darren Hobbs

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.

Posted by Darren at 04:22 PM | Permalink

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

Posted by Darren at 02:46 PM | Permalink

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?

Posted by Darren at 08:53 AM | Permalink

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

Posted by Darren at 08:31 AM | Permalink

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.

Posted by Darren at 07:56 AM | Permalink

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.

Posted by Darren at 08:09 PM | Permalink

Tim Bacon has started a blog. Cool.

Posted by Darren at 01:04 PM | Permalink

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.

Posted by Darren at 08:32 AM | Permalink | Comments (2)

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. ]

Posted by Darren at 08:02 AM | Permalink | Comments (1)

Word of the day from the pseudodictionary:

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

Posted by Darren at 07:45 AM | Permalink

The following books should be mandatory material for anyone who works with other people:

• Out of the Crisis, and also, The New Economics - W. Edwards Deming.
• Good to Great - Jim Collins.
• Congruent Action - Gerald Weinberg.

Thank you.

Added on 21/07/03 in response to comments: They're all books that really open your eyes about the nature of working with others, what quality really means, and what it takes to build a truly great company and have fun while doing it.

Posted by Darren at 01:07 PM | Permalink | Comments (3)

Shamelessly lifted from Chris Winters' blog: http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html.

Funny, but so often true.

Posted by Darren at 09:48 AM | Permalink

One of the laws of physics (can't remember which) states that entropy always increases. Put another way, a local decrease in entropy must cause an overall increase. This is how refrigerators work. Lowering an object's temperature also lowers it's entropy, however, the heat given off by the coils at the back is increasing the entropy of the surroundings (by raising the air temperature), thus overall entropy goes up. In heat terms, the heat dissipated by the coils will be greater than the heat removed from the contents of the fridge.

The refrigerator analogy works rather well for software. Any time a developer makes a change to some code, its entropy (ie. software entropy, which in this case can be considered 'disorder') will tend to increase. In order to maintain the same level of entropy in the code, the developer has to put in more effort than strictly needed to just make the desired change. This effort might be expressed as adding extra tests or refactoring around the changed code. The extra effort takes energy (time + brainpower). To maintain the code's level of entropy when making changes, the overall entropy must increase - measured in this case by the extra mental effort causing an increase in temperature of the air around the developer's head.

Posted by Darren at 08:11 AM | Permalink | Comments (1)

How do you make a maintainable system? Make all your developers spend at least some of their time doing maintenance and support. There is no better way to really see and feel the impact of all the ad-hoc decisions that get made when developing.

Posted by Darren at 07:31 AM | Permalink

Spring: http://www.springframework.org/

Posted by Darren at 09:30 AM | Permalink

One year older and hungover.

Posted by Darren at 09:05 AM | Permalink

So today I learned that the current state of the art in reliable scalable peer-to-peer network communications owes a lot to neighbours gossiping over the garden fence and the study of disease epidemics. Cool. There's an obvious similarity to the way computer virii spread as well. Each message 'infects' the receiving node, which then spreads it to surrounding nodes. Once a node is infected with a message it becomes 'dead' to that message, thus preventing endless retransmission. The gossip part comes in when you need to pick up on missed messages. Each node chats to its neighbours along the lines of 'Have you heard the latest news about Mabel down the road? No? Let me tell you...'

Just goes to show that whatever wondrous things humans imagine themselves inventing, nature got there first.

Posted by Darren at 08:38 AM | Permalink