“‘Who wrote the spec?’ – A tool to support effective requirements communication in software development” was the title of my masters dissertation dated August 2005- possibly the driest title in the history of titles ever . This was getting on for four years ago – which is not long unless you consider I have only been at this for six years.

Anyway, the software was a rather drippy user interface for recording and tracking user requirements. What is more interesting is to understand my attitude to specifications and requirements in general and how it has influenced into the beliefs I hold now.

At the time, specifications meant to me a document written in MS Word with a different section for each page/form dialogue with sentences such as:

When the user views the page he/she will be presented with the following items:

• A list of users who belong to his/her organisation. For each user:
  • The full name of the user
  • An ‘Edit’ button taking the user to the user edit page (see section 1.2.24.2.2.2 below)
• An add button taking the user to the add user page (see section 1.5.252.352.235.235 below)
• Help text explaining that the page shows the list of users for his/her organisation

These specifications went to the client, who OKed them before we started working. We implemented everything ‘according to spec’ testers tested against the ’spec’ and if the client was not happy with the end result, we would grudgingly change the application then update the specification.

Well. This was supposed to be how it worked. More often than not, we would start coding and realise the specification had a few holes in it so we changed the implementation. When the project was finished, the tester started testing against the specification. He/she would notice that there was something not done to spec and would raise a QA point. Us developers would fling it back to them muttering insults about stupid testers under our breath.
Then the clients would come in to see our work. They would say ‘we didn’t want it like that, we wanted it like this…’. Developers again roll their eyes and mutter about ’stupid clients who don’t know what they want and anyway didn’t they read the spec?’ (answer probably being no as it had a readability score of about minus ten).

This is a bit of a generalisation and doesn’t really account for the talent and resourcefulness of all the testers/PMs/developers involved – this is what contributed to the success of the project far more than anything that went in to the specification.

So why was I such a big fan of specifications? Well, I could see that there was something important happening there. Alongside all the copy/pasting, form text and deeply nested lists I was performing a valuable function. I actually had to sit down and think through the project as a whole. As I got more well-read into the murky world of requirements, I started trying to write the documents in plain English, using ubiquitous language from the domain, identify why we were doing this in the first place, figure out who the stakeholders were. Even though the document went out of date the moment I wrote it and was basically a bit of a nightmare to maintain (hence the need for my dissertation project…), the work that went into it really helped with the development.

At the time I was writing my dissertation, I used my copious free time and access to our university library to read through some of the ‘classics’ – pragmatic programmer, peopleware, Code Complete , and Kent Beck’s XP Explained book. I remember my reactions to this as being ‘brilliant brilliant brilliant… but, it implies specs are bad so I must ignore it…’.

Fast forward a few years and I start working at a company who have fully adopted agile methods to great success. We are sitting round in an iteration planning session talking about why we are doing this bit of functionality, who it is for and other such questions. And finally it all clicks – the same brain muscles I was exercising when writing my big old word documents are being worked here. It’s just that this time, I am not doing it on my own (a good thing!) and I can’t even get away with calling the testers/clients stupid because they are all in the room and know exactly what is going on. Oh and epic word documents have been replaced with scribbles on extra-sticky post-it notes…

Now don’t get me wrong, I was never against agile methods, more admiring from afar and a tiny little bit intimidated by the whole thing. But having this epiphany that I was sort of along the right lines in the bad old days gave me a massive boost in confidence – and turned me into the wonderful, well rounded developer that I am today. *

* This last comment might be slightly exaggerated