Over the last few years the ethos of 37 Signals has formed the core of my development process. Keeping things simple. Doing less instead of more. Appreciating the critical role of design as a counter-part to programming. Interface led development. The importance of copy writing. Small teams, minimal planning, getting running REAL code up and running ASAP.
However I have found their writing has become “in house” development centric, and they seem to of forgotten that most software projects are for paying clients. In the interview entitled Less is Better for UX Magazine, David Heinemeier Hansson (a partner at 37 Signals) spoke of functional specifications as outdated.
I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don’t think that functional specs is a technique that’s any longer relevant. To me functional spec is a dead document. It’s an illusion of agreement.
I have very similar thoughts myself. For my side projects there is no way I would draw up a functional specification. What purpose would it serve? At the start of the project, I know the least about what the software should do. I am at my most uninformed, so it is irrational to try and plan the small details. Instead I start building the interface in real code, so I can see, feel, and start understanding the problem. If I am being organised and disciplined I will implement in 1-2 week sprints to keep my motivation high. As a team of one working in my spare time I am agile.
However my clients are unlikely to accept the lets get going, pay by the week, and work it out as we go along approach. Like any other industry, clients want to know upfront what they are going to be paying (price), what they will get (deliverables), and when they will get it (delivery date).
The software world is ridden with this stigma that we can never deliver anything on time. We can never deliver what the users want, and tons of projects end up canceled. So I say the predominant development process has shown itself to be broken. Once something is truly broken, it’s a lot easier to face facts and try something else.
In a lot of industries the price, deliverables, and delivery date can be accurately predicted. Unfortunately our industry cannot devise accurate predictions due to the complexity and uknowns of software. The price and deliverables are fixed upfront and so it is the remaining variable, the delivery date, that changes. This would explain why almost every software project is late. David Heinemeier Hansson poses a time box billing approach.
So the techniques are to use a time box approach—a week, two week, three weeks, whatever you decide on, just schedule for that time box—one time box at a time and you can also just set a budget. So the most this project can cost me is $50,000. Well, divide that by the hours you can buy at a given rate from the developer and you’ll end up: Okay, we have six boxes of three weeks each, so I have to arrive at some usable software within the scope of six times three weeks. Well, that’s pretty cool because you can now see after you’ve spent one of these time boxes, am I getting the right way, am I liking where this is going, do I need to change the course, and you can constantly alter and adjust where the project is going. And if you’re happy after four weeks, if you like the software that you have then, fine, you just stop. If after six weeks, you realize that the original budget is spent but this software is so valuable, you’re getting so much good stuff out of it that it’s going to be worth another $50,000, you just keep on going.
What a brilliant option for the development house. The project cost and completion date don’t need to be predicted, so we can’t under price or miss a grand deadline. We invoice at a nice hourly rate for the exact quantity of hours we use. Fantastic!
However can you really imagine pitching this approach to a client?
We have this new method we want to use for your project. We don’t promise to deliver anything from the outset, we can’t tell you when we are going to be finished, and our service will cost you $2750 dollars a week. Oh and if we use up all your money after 18 weeks and you don’t have a finished product, go away find some more and we can continue working.
My pitch is jovial but it demonstrates the hard sell, and why a client is usually not going to jump at the agile no functional spec or upfront cost way of working.
The functional specification is a way for the client to protect themselves against under-delivery, and it in turn also protects us as a development company against over delivery. If we don’t have a specification there is no cut off on the features the client can request. Feature creep costs us real money as a development company, so the feature list must be carefully defined from the outset.
We try to foster a ‘give and take’ relationship with our clients, so we can revise and add, modify, or remove features as we become more informed later in the project. However if things ever are to go sour, the document protects both parties.
So is the functional specification dead? Yes and No!
Yes it is a dead document which is seldom looked at and rarely influences the project during the build. No because we would be hard pushed to pick up new business without it. It is therefore a necessary evil.
