Big Boxes

I like to work in an Agile project environment. Recently I have found myself in the happy position of being able to work for a client who is really buying into the whole Agile movement. The client is a very big telco, so its systems need to be... well... very big too.

This presents a few problems. One which is on my mind right now is how to size and budget for buying suitable hardware to host our new system. At the moment, we have tackled some of the lower volume products but in later cycles we will be doing some really big stuff against some really imperative deadlines.

We dont yet have detailed requirements for the big stuff (it's Agile, remember?), but we need to put a box in place which is going to have to cope with them. How to do it? Here are a couple of options...

• Rely on commodity boxes and horizontal scalability. That way, we can roll out incrementally and we dont need to know up front how many boxes we will eventually need. This works well for the app server tier, but is of less help for the database tier.


• Get the best picture we can of upcoming volumetric requirements (I dont think we can bet on 'You Arent Going To Need It') and pick a hardware range with enough memory, processor etc expansion capacity to support the eventual need.

To further complicate matters, we need to budget for floor space in the data centre - if we get it wrong, we may find that our boxes are hundreds of miles apart, which isnt going to do much for latency.

Challenges to Agile Development

It must be at least 12 years now since I attended the excellent two day course entitled 'Object Oriented Project Management'. Frankly it wasn't much about Object Oriented development and would perhaps have been better entitled 'Enlightened Project Management'. It introduced me to concepts like Boehm's spiral lifecycle, Tom Gilb's evolutionary delivery ideas and books of wisdom like 'The Mythical Man Month'. I had zero project management training prior to this but the wisdom on this course rather ruined me as an audience for the purveyors of more traditional project management techniques who have crossed my path since then.

As a result of this and my experience since then, I have become an advocate of agile development approaches (although it wasnt called 'agile' 12 years ago!). I have also encountered a lot of situations which pose challenges for agile practices. The main ones are:-

• Management of non-functional requirements - agile user stories tend to focus on obvious functional value. The fit of agile techniques to cross-cutting (but critical) concerns like security, performance or availability is less clear. Some have proposed non-functional user stories, but at the moment I think the jury is out.


• Outsourcing - having a customer/supplier relationship introduces barriers in communication, potentially conflicting motivation and reward systems and, in its usual form requires some form of big specification up front saying what is being paid for. All of these are driving us in the oppposite direction from the Agile Manifesto.


• Offshoring - an extension of outsourcing which introduces the additional challenges of physical distance, poor communications infrastructure, timezones, language and cultural differences - all of which conspire to hinder the free flow of communication which is the life blood of an agile project.

I dont claim to have all the answers to these issues. Some would say that a 'high ceremony' methodology is the only answer, but I'm not so sure. I do find myself facinng them on a regular basis, so at least I have some material for future posts!