Is there any single way in which you can develop a piece of software that doesn’t do what users want? Yes, write a functional specification document!
Before saying anything else, I want to clarify that I’m talking about typical software projects… web, desktop or mobile apps; not about space shuttle operating systems, or real time controllers for robots that do brain surgery!
I can almost hear all of those functional spec lovers yelling all kind of things at me. – “Are you crazy? Functional specs are supposed to help us in delivering good software, products that do what the users want.” Well… usually we achieve exactly the opposite by creating this documents.
This is one of those areas where reality shows us again and again, how wrong we are.
Please, try to remember any software that you have developed, that once it was finished, still kept quite close to the initial functional spec… I couldn’t. And I know a lot of good software developers with this same dilema. The reason is simple, functional specs are theory, not reality. Of course, we could try to maintain them close to reality and in tune with all the changes and evolutions as we develop the software, forcing us to strictly change first the specs before doing anything else. But then… why bother? Isn’t it supposed to help us? If we have to change it day in and day out, every time we want to make changes, does it worth it? Does it slow us down?
In my own experience with all the corporate clients that I worked for, they always had required some kind of detailed functional spec before starting to build the software. The best scenario was to have a software very different to the initial spec, but fortunately aligned to the client needs. Sometimes these specs where updated, sometimes not. But we always had a lot of overhead with back and forth discussions with clients about what was a “requirement change” and what was a “misinterpreted requirement”, and then rewriting the specs or writing new ones.
And the worst case scenario? Well… if those were some of the best cases, I guess is not necessary to explain what happened when we weren’t so fortunate.
Over the years I came to discover some truths about software development and functional specs, the hard way… hitting my face over the wall. Most of these issues were addressed by other people, and I only wish now that I could had the chance to understand them better back then:
“So great genius… if we create no spec, how do we start? Do you suggest start coding right from the beginning?”
No, not at all. But I’m for things that really help you build your software, and don’t get in your way. What I really found that works is to start with a really small description of the product or software that you want to build and some UI draft sketches. This will really help you visualize the software you want to build, and to communicate the ideas easy and with low overhead between team members and with your client. The natural evolution of these steps is to start building the real UI, with no functionality.
“Hey! Wait a minute… isn’t that a kind of spec?”. Yes it is, but a different breed. One which is simple and agile enough to help you and your client to agree, and to move on to the real work… getting the product done! I’ll be writing about this process on some future post.
From my own experience, I got the bests results when I kept focused on less documents, more agility, and using the right tool for the job.