sigh

Once again the ugly "Process" word has reared its ugly head..

For those of you not involved in Software Development it would seem that an unfeasibly large amount of time is dedicated to this word, trying to define the perfect process (or methodology, if you will) for producing quality software..

Once again, however, it would appear that the approach undertaken is all wrong, wrong, wrong.. before I knew it the whole meeting had launched into a lengthy discussion about what documents need to be produced and whether there should be checklists or reviews of these documents, yadda.. yadda.. yadda..

So we're basically back to defining a Document Development process..
At no point did anyone (in authority) say: "Hey why don't we spend some time on defining a way of ensuring that the products we deliver to the user are of the highest quality, meet all of the requirements and are delivered within time and budget".

You see, after the meeting (once I'd finished spitting blood and there was no longer steam coming out of my ears) I realised that the approach undertaken was all wrong.. People were already thinking about what documents need to be produced, and who needs to be in review meetings, etc when really they need to turn their thinking around a little.

Now before I get lambasted by anyone, yes I hold my hand up: I am fond of agile methodoligies and approaches such as eXtreme Programming in order to develop software solutions. But before you declare me the "Anti-Christ of Documentation", accept the fact that I realise that there must be a certain level of documentation. As we have external customers for our software they expect a certain amount of documentation in order to sign off agreements so that we can go ahead and actually write the fucking software. Also we are audited by all sort of Quality bodies, and I know they will expect to see evidence of a process being followed, and some documentation should be presented as evidence of that..

But..

and it's a big but..
(not a big butt, that's something entirely different)
It's such a big but, let's make it bold..

But..
that's better..

We are a Software Development department. The primary output of the department should be the software solutions we provide. Let's first look at how we can make them of the highest quality, and then see what comes out of that process in terms of documentation.

So what is quality software?

Well I'd argue (and by Christ, I think I'm arguing to myself here, but I'm on a roll here so don't stop me now, if you're bored go search for some porn or something), that quality software must fulfill the users expectations, in terms of meeting their needs and requirements. It must be reliable (so it cannot meet their requirements, but crash every five minutes, that won't do). It should be maintainable (so if the user has further requirements in the future, we are not required to re-write the system from scratch because no other fucker understands the system delivered and the original programmer fucked off to work for our competitors two months ago). It should work

Okay, I'm over simplifying here, but people have written books on this shit and, as annoyed as I am, I don't intend to write a novel myself this evening.

So in order to ensure that I have delivered a quality system I must ensure that I fully understand exactly what is required.

How do I do that?

Before anyone shouts "Write a specification" (actually, don't. Not even in jest. Don't make me come over there and slap you stupid), stop a minute. First I need to know who wants the software, I must identify the customer, the person who needs the information that my system will produce or requires me to model the process they hope to automate. If I don't know who they are, then who the fuck am I going to go to to find out what needs to be done?

So.. firstly locate the appropriate people from whom I can get this information from.

Now, as self-important as they like to be, this may not necessarily be a list of directors and upper-management (as in my experience they know fuck all, apart from how to draw a massive salary and sit in their offices listening to their arses getting fatter). Of course it might be them (depends on the size of the company I guess), but they might not actually be close enough to the process I'm trying to model to actually provide me with any relevant information. They, of course, might need to bankroll the development, and should be kept in the loop somewhere (maybe as something like a project sponsor or something). But, in most cases, in terms of what I'm actually expected to deliver, they probably don't know their arses from a hole in the ground, so they should never be the person I speak to if I need to find out what the software actually needs to do, or later on if I find that one of my requirements is a little ambiguous and requires some clarity.

So I assemble my little list of customers or users or whatever the fuck you want to call them (seriously, I don't care what you call them. I know every methodology has a variation on a theme as to what they should be called but this is superfluous detail in my fucking opinion).

Actually, for the sake of argument, let's call them Wookiees.

So I have a list of Wookiees.

The Wookiees possess the knowledge that I need to capture in order to know what my software needs to do (and most importantly to let me know when I'm done).
I also need to agree with the Wookiees that they're going to be available for me to get information from them, no point appointing a load of Wookiees if they're going to be working for the next six Months in Australia and will never turn up to a fucking meeting (whether I put a reminder on the meeting request or not).

Also it's no good someone giving me a list of Wookiees, when the Wookiees have no idea they've got any involvement in the fucking project, as the Wookiees probably have their own work to do and will be quite pissed off when I come along badgering them for information when they're trying to get the rear stabilisers on the Millennium Falcon fixed.

So I have a list of Wookiees who have agreed to work with me to help me deliver my software.

Now, to me, that seems to be some sort of project deliverable. It's a document that details who is available for me to go talk to when I need some information (stay with me you Agile developers, you have nothing to fear except maybe a slight paper cut (and then only if you print the fucking thing)), it has the names of the Wookiees, maybe the department they work in or their job description and maybe (if we're feeling adventurous) their telephone extention or something. This adds value to the process of developing the quality software as I now can always refer to this list to find out who I should speak to if I run into a problem later on, or when it comes to gathering requirements.

Therefore it's not a document produced just for the sake of producing a document.

Shit, this is actually handy (particularly if I'm not the coder who is actaully gonna write this, some other poor sap might need to pick this project up later now he or she knows who can help them out too!). It might even detail who's paying for the fucking project (as they might need to give me some go ahead later, but we've not even got there yet, so let's not worry about it). Right now, all I imagine is that on a sheet of paper I have a list of Wookiees (as this is all I've considered about how I'm going to produce my quality software), but it's a fucking start.

So now I need to get the information from the Wookiees about what the fuck they want..

Now I'm not going to go on and on and end up writing my own Utopian software development process here, and I will probably find that even here there's a couple of things that need to be ironed out to really make it work.

However my point is that I'm coming at this from the angle of "How do I ensure we deliver a quality software solution" as opposed to "How do I write a shit load of documents".

Documents may ultimately be a product of some of the things I ultimately end up doing and if they add value to producing my software (as I'd argue my list of Wookiees did above) then I don't see it being a fruitless task to produce them.

I wish I could convince a couple of other people to think like this, and just consider what it is that Software Engineers actually need to produce as I'm sure it would make everyone's life a lot better (particularly the poor Wookiees who end up using the bloody software), but instead I'll just get it off my chest on my blog.

Gonna hit the brandy now, thanks for listening (if you stayed this long)..