Now, where the hell is THAT mentioned in the Spec???

This will be my first actual Posting related to what I do, so please be gentle!

DISCLAIMER

Firstly, I’d like to say that this article is not intended to to have a pop at individuals, rather the problems with processes which can give developers cause for frustration. They’re just my generalised opinions, and examples are here just to put my blog entry into context.

Cups and Lids… man I’m thirsty!

I’ve just read a recent, albeit small, Blog entry which highlighted the gap between stakeholders requirements and end products delivered within the software process. They summed it up in BASIC code….it was typically succinct but it made a valid point.

It got me thinking about a lunchtime conversation I had with a fellow colleague who summed the way the traditional lifecycle works for many places, and indeed my current workplace. So I thought I’d have a go at writing about it.

He analogised with a Drinks Cup from a Fast food Restaurant. To Protect the guilty, we’ll call it FFS or Fast Food Stores, or make up your own acronym of course!

I’m paraphrasing and adding artistic license, but here’s that fictional conversation between a PM and a Developer they created in that analogy, which I hope sums up the problem…

PM: Ok! For our Customers, FFS , We’d like a Soft Drinks Cup, as specified here… and we want it in X days….

< time passes…>
Dev: OK…Heres the Soft Drinks Cup you asked for…..

PM: The Cup is good but we just realised need a lid..

Dev: OK … thats wasn’t on was the original spec…. so you want a Lid? OK .. I’ll go make a lid

<more time passes…>

Dev: OK, So i’ve done the Lid.

PM: This isn’t the kind of lid we want.. it doesnt have button to signify if the contents are Diet..

Dev: but you asked for a lid, so I made a lid!

PM: but we want this too…oh and its missing a straw hole…. and we would like it in the time we allocated for Cup…oh… The deadline for getting the cups out to FFS was yesterday….

Dev: <bangs head against the wall several times>

All too often, this is the kind of the problem I’ve seen in my relatively short career in the industry, and not just in a Dilbert Cartoon.

The problem is, you might think as a developer you’ve met the requirements with the end product, but then the requirements that were set out originally:

• Did not cover important aspects which were core to the solution being realised.
• Didn’t consider adequately the impact on dependant or legacy systems.
• Changed mid flow due to stakeholder pressure.
• Didn’t cover what the customer needs correctly early on in the process.

The list above is probably not exhaustive, are just 4 of the kinds of things I’ve seen.

“It’s OK….We’ll make it up as we go along….”

in particular, I’ve had recent experience of the first and the second point.

For example, I’ve seen a spec document was so sparse, that in many cases one line of notes became the spec for a large chunk of functionality!

This meant that when the document was picked up by the dev team after initial development review and the development was started, It needed several pages of amendments in a section reserved for development decisions. This a section which should be kept to a minimum, for small decisions.

These additions were just to cover all the scenarios not fully thought out, and to allow the new system to work with existing legacy system’s functionality. It meant some radical changes, which had there been more awareness of these, less work may have been needed and more understanding of the requirement would have been gained.

This suggested to me, that the spec really needed a further review before proceeding, involving at least the lead developer of the team working. This is could have been done once the existing functionality and dependencies had been reviewed within the development environment.

Or it could be that the process of gathering requirements, speccing it up, and development may not be appropriate to the environment.

Now I’m aware that the problems I’ve seen in practice may be unavoidable, and that can sometimes be necessary to work in this way. But I’m sure there’s got to be something out there could reduce this, which is why I’m watching a recent development at work with some considerable interest…

Into Agile, The (Not So) new way of thinking….

One of the guys has managed to persuade the boss to allow them to trial Agile Development methodologies (e.g. Xtreme Programming) on one of the projects in the department, which is looking promising.

It appears to give a much more incremental approach to the development life cycle, with shorter times between reviews. It appears be far more collaborative in nature, that engages the participants and gives a better understanding of the requirement.

The Agile story so far…

The project has been running for a little while. There was some initial resistance to this approach, as there always is to new things within a well established and, in this case, traditionally minded software company. But, now most of those new to the approach seem to be keener on it as it’s being used. Its highlighted some of the weaknesses above, along with other things like underestimates in Timescales. Whether there is a more permanent change in the mindset of those involved remains to be seen, but I for one look forward to working with this in anger in the near future.

No doubt I’ll keep the blog posted on how its going…..