Back in the days when I worked on mission critical systems I was indoctrinated in the philosophy of following a process. There were the strict, almost unbending, documentation requirements. These were bound tightly to the development process. On top of this were the strict design, coding and testing requirements. You had to have plans to n degrees of details, with costs and timescales worked out to the day for projects lasting many years.

It was of course utter bollocks. Yes, even for mission critical. If only I had realised that then!

Fast forward to today. Now I do web design and software engineering. The kinds of clients we work for are different. But like those early days in my career, many clients still don’t know what they want, even though they might think they do. There is at least one project I’ve worked on for which I wish I had never written its specification.

As a result, much of what we do as a company now is a bit more touchy/feely. We have short specifications, perhaps no more than one page, or a couple of paragraphs. The purpose of this is to reach a general agreement. Our clients are reasonable. They recognise things may change and because they don’t know what they want exactly, they’re happy with the vagueness of our outlines. For larger projects we now aim to show clients work in progress. This gives them an opportunity to provide timely feedback and for us to change the direction we’re going in.

It’s called Agile Software Development. But it’s not new. Here’s a Manifesto for Agile Software Development written in 2001.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.