Most software projects seem to go on an emotional roller-coaster voyage. Initial euphoria soon fades into confusion, followed by despair. If a project is going to succeed in reaching port, despair is followed by a consensus decision to save as much as possible from the wreckage of the initial ‘vision’. Maybe I’m unlucky, but I’ve never worked in a project where the voyage didn’t involve a storm and a near-shipwreck. In projects that are doing to fail, despair is followed by resignation; a state of apathy as the rigging crashes around, and the rats desert the sinking ship.

Quite often, in a development project’s stage of apathy, I’ve been hired to report on the problems affecting a development project and to try to suggest rapid ways of ‘turning the ship around’.

The problem that confronts any ‘consultant’ faced with providing a simple picture of the state of a project and the solution to its ills, is to turn a mass of conflicting, and sometimes irrelevant, information into something sensible and intelligible. Most problems besetting a software development project are complex and diffuse. Very rarely, however, one gets the delightful experience of accidentally stumbling on the simple nub of the problem straight away.

It was one of these experiences that I remember as the ‘Sticking Page-Down-Key incident’.

It was a telesales application, I remember, that was being developed by the IT department of a well-known company. The distraught manager showed me the ranks of telesales people in the vast open-plan office, trying, and failing, to use the initial release of the software. Most had reverted to the previous system.

I talked to all the team members individually, and read through the project documentation. If I were to believe everything, then the project was in wonderful shape. I didn’t, because it wasn’t.

I was beginning my rounds once again when I settled on the team writing the client application. I started to talk to one of the team members, using my usual trick of pretending to be even more stupid than I really am. I asked him about the technology; He gave me a ‘Word Salad’. ‘Word Salad’, I should explain, is a technical term that describes the way people cover up their confusion, or lack of knowledge, by stringing phrases together in a random order. It is an attempt to bluff the user into believing that the words convey subtle meaning too intricate for the listener to comprehend. It is much used in IT to cover-up a lack of knowledge.

I find being the recipient of a ‘Word Salad’ particularly irritating. Whilst fidgeting around, willing him silently to stop, I accidentally leant on the keyboard and the ‘Page-Down’ key.

I stared transfixed at the screen. Initially, there was a flurry of movement on the screen and then nothing, just static text: Nothing, that is, excepting for a number changing at the top of the screen. I took myself off the keyboard. The number stopped moving. Pressed the Page-Down again: a twitch of the number, but the rest of the screen static. After what seemed like an age, the screen suddenly burst into flickering life.

This programmer had been making a large number of SQL calls to the database, just changing one parameter every time. It just so happened that each iteration took exactly a screen-height when the editing window was maximised.

I scrolled back to the start of the source-code file and pressed the Page-Down button again. When you hold the Next-Page button down whilst viewing source-code, the scrolling is so rapid as to be a blur, creating, on the screen, an animated line on a white background. It wiggles from the left slightly as code gets indented. In this case, it wiggled, and wiggled, across the width of the window, and on until it disappeared off the right. Page after page flashed by; occasionally it wiggled provocatively into view from the right hand side, like a fan-dancer from behind a curtain, only to wiggle off-screen again.

I sat mesmerised.

After what seemed like an age, the blurred vertical line of code wiggled firmly back into view and gradually across the screen until finally it laid itself to rest once more on the left hand side. End of file. No procedures, No subroutines, just stream-of-consciousness coding.

A few straightforward questions elicited the obvious fact that he knew less about programming than I did about Chinese ballet. It was a curious thought that his code had been peer-reviewed, a thought that led me to look at the code for the whole team.

When I broke it to the project manager that the team probably had many talents and skills, but he was not to rely on any programming skill from them, he was nonplussed and showed me the CVs. They were so good I had the sudden uncontrollable urge to hire them on the spot before I shook myself fully awake.

With everyone’s consent, I arranged for the CVs to be checked out by a specialist. It is, perhaps, little known that CVs can be checked through very easily for their truth, for a modest fee. When my researcher phoned back, he was gurgling with laughter. They were almost completely fictional. Qualifications and experience were completely invented. Nothing checked out at all beyond the basic personal information. They were all contractors and all hired from the same agency. They were all appointed at the same time. As it turned out, they all left at the same time, leaving a project headed once again on the right course.

I’ll be the first to admit that this was an unusual occurrence, and it was strange that the developmental methodology, or team processes, had not rapidly highlighted the source of the problem. However, real life seldom goes quite like the book says it ought to, and the reality of the software industry is, just occasionally, more absurd than one would dare to imagine.