A Reverie On Process

It should be pretty apparent from what I post on this blog that I’m a process-heavy writer. There’s lots of reasons for this, but many of them relate to seeing how process works and does not work in software development.

My software career started back in the days when the only methodology taught in Universities was the waterfall model: collect customer requirements, write the spec, write the code, test the code, perform acceptance tests with the user. It was sometimes represented as a valley with implementation at the lowest point, matching each of the implementation stages with a corresponding verification stage on the other side, but that was only to show how the results from one stage could be used to verify the output of a later stage: the intent was that a new stage would not start until the preceding stage had been completed.

Waterfall has always been an attractive model from a planning perspective because you can add up how long each step takes to give an end date. This process might work for bridges and roads, but it is completely unsuitable for software because so much of programming is craft rather than science: software is astoundingly complex and very hard to estimate accurately – a planning model which doesn’t allow for responsive change is more or less guaranteed to fail. This is why agile processes are so prevalent these days: you’re trading apparent certainty of end date for actual certainty of functionality and responsiveness.

Another set of processes which have a bad reputation in software circles are ISO-9000 processes. ISO-9000 is a set of standards for quality. Broadly speaking, an ISO-9000 process is about writing down what you are going to do, doing it, writing down that you have done it, and then checking that that work was really done.

These processes can be onerous. Indeed, I’ve worked for a couple of organisations where they’ve introduced ISO-9000 processes so as to get certification for tick-box compliance and the processes were a stultifying layer on top of an otherwise functional development process: the ISO-9000 review cycle got in the way of doing the work, and it was roundly despised as a result.

I’ve also worked for one company where the ISO-9000 process was built into the company from the ground up: the company had started working with the MOD standard that turned into BS-5750 which was itself the basis for ISO-9000. The interesting part of this process was a standard for documentation of activities.

Let’s take the structure for meetings as an example. There was a standard form to use for recording a meeting, but there were designated roles: chair, minute taker, and presenter. You could conflate the minute-taking role with one of the others if you were short of people, but the intent was always to spread the responsibilities around.

During the meeting, whenever a decision was made the minute-taker would note that decision. Every meeting had an agenda, and the first item (after writing down the attendees) was always to review minutes from previous meetings to see if actions were completed. At the end of the meeting, everyone who attended had to sign off on the minutes to show they agreed with the decisions made.

What this process did was to give continuity from one meeting to the next, and to hold people accountable for completing their actions. Team members could go back and use that documentation to track where requirements came from. It was invaluable for dealing with employee churn* and client disagreements (staff were always told to volunteer to take the minutes at client meetings).

And that is why I am fairly process-heavy in my writing: I like to be sure of my steps, and since I often can’t spend more than half an hour in a straight line on the work I need the tracking to be able to recover state when I pick things up.

Do you have any favourite processes you like to follow in your practice?

[*] because the process was the best thing about the company.

Leave a Reply