Read the Specification. Please.

I think that more software projects fail because of misunderstandings about the specification than for any other reason. The developer makes loads of assumptions about what the program needs to do and the customer can’t be bothered to keep an eye on what is being produced.

I was reminded of this when I was marking the first year coursework today. We set a tightly specified set of deliverables and then each student has 15 minutes to show what they have made. This is a lot of work. It takes five of us two and a half days to work through everyone. And then I have to spend at least two days going through the marked sheets and making sure that all the marks line up.

This year we set some quite complex deliverables and it was very pleasing to see that many students had risen to the challenge and produced some lovely stuff. But some of them had made really nice solutions to the wrong problem, because they had not read the specification in detail. They’d just read enough to convince themselves that they knew what was needed and then gone off and built it. And in many cases they needed to do more work to make their version than they would have needed to make the one that was required. Oh well.

Of course in a teaching situation this is not a huge problem. Folks lost a few marks and we moved on. And hopefully a lesson was learned, which is what it is all about.

One year I’m going to produce a huge, complex piece of coursework with a long and highly detailed description which has, right at the end, the phrase “Please ignore all the above. Just make me a program that prints “Hello World” in large friendly letters.”…