Software Reality
Programming with
a dose of satire.

Site Map Search

Agile Development
Extreme Programming
Code Generation


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide

Check out our ageing Reviews Section


Fear of Non-Progress

By Matt Stephens
December 17, 2001 (updated September 5, 2002)

This article is divided into the following pages:

The Waterfall Effect
Increase Communication
Tackle the Problem Head-On



Steady progress...

Most middle managers love to see source code. They love to see reams upon reams of source code, the earlier in the project lifecycle the better. This to them represents progress. If "90%" of the project code has been written, then the project must be "90% complete".

The same managers balk at the notion of spending time up front gathering requirements, writing specifications, laying down the groundwork for a project where everyone is on the same page. This to them is non-work, as the project does not appear to be any nearer completion. Six months might have gone by without any code having been written.

This problem is exacerbated by a common tendency to take a "waterfall" approach to development. All the functional specs must be written, then all the design specs, then all the code. Then everything is integrated in one big swoop, and integration testing takes place for the entire system, then user acceptance testing takes place. The customer does not get to see any real evidence of progress until right at the end of the project.

"The customer wants assurance that you are following a low-risk process"

It's understandable that management balk and panic at the prospect of this sort of high-risk process. They don't see any working code until late in the project. There is no sign that the project will be brought in on time, even with the project manager's earnest-faced assurance that everything will "suddenly come together on day 347 or therabouts". To the senior manager, this is a terrifying prospect, and understandably so. Managers at this level need to see tangible progress, and they don't have time to learn the finer aspects of process engineering in order to appreciate that the project really is on track.

Of course, it could be argued that they should at least understand the basics, because after all, they are in charge of a software project. But does that mean that the customer should also be educated in the same way? And the "power behind the customer", the moneybags to whom they must justify the project? The answer is probably yes to an extent, if this was an ideal world - but of course in most cases it just won't happen.

Therefore, if the customer won't "play ball", or cannot reasonably be expected to learn our rules, we need to change our ball game to suit them. To translate that into English: the customer doesn't have the time or inclination to learn about software methodologies. We are the programmers, after all. They just want working software. So we need to give them that, and to actively demonstrate they we are in the process of giving them that, throughout the project.

The customer will want assurance that you are following some sort of process (and a low-risk one at that), but beyond that they probably don't care about the details. All they care about is what they are going to get, not how they are going to get it. That's your problem. The customer will make appreciative noises and agree wholeheartedly that they need to know more about the process your team are following - but then the next time you speak to him, it will be as if the conversation never happened. Life is like that sometimes.

"Convey a sense of rapid development"

Fear of non-progress, then, is a real problem. Clueless managers (who really should know better) will encourage you to leap straight into the programming. To them, code = progress, therefore coding = appreciable activity. If the requirements gathering has taken too long, they will push for you to skip the design phase altogether, and to just "start making some progress."

So what's the answer? How do you get those all-important requirements and design phases out of the way without terrifying your own managers and the customer?

The answer is really in two parts. The first, and most important part, is communication, conveying a sense of rapid development. We'll cover that in a moment. First, though, it's worth reviewing the process itself, and examining an insidious problem that can manifest, even on projects that don't set out to follow a "waterfall" process...

>> Page 2: The Waterfall Effect



<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.