Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

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




Lifecycle

Fear of Non-Progress

<< Page 2: The Waterfall Effect

Page 3: Increase Communication

There is always a danger that your project, however well it is progressing, may give an impression of slow progress.

This can give rise to all sorts of problems, e.g. senior managers decide to "crack down" on the project; insist on unnecessary and time-consuming daily updates; try to embellish the process with their own "best practices" which just hinder the project; mix staff around; reassign the project; or worse still get cold feet and can the project entirely. Frustrating, when you knew that the project was doing well. All you had to do was convince them. This is where communication comes in. It's an essential part of the mix.

Steve McConnell writes about the perception of slow development in Rapid Development: Taming Wild Software Schedules (Microsoft Press). The first thing to do is eliminate wishful thinking, and make planned schedules more realistic. If expectations are reasonable, everyone can relax and get on with it without resorting to that most time-consuming of development modes, panicky hacking.

"The quality of the product inevitably suffers"

It isn't always possible to convince management to allow you a reasonable deadline. Market pressures mean that the deadline is regarded as immovable (e.g. go live in mid-September ready for the Christmas rush). In this case, the only possible way to achieve this is to cut down the amount that will be delivered. The customer can have some of what they want by their proposed deadline (and get the rest later), or they can "go for broke" and almost certainly end up with none of what they want.

Taking this reckless approach, the quality of the product inevitably suffers. They might get what they want eventually, but it probably won't be until Christmas the following year. It's even more likely that they will end up with a buggy mess that has to be scrapped.

In this instance, it is vital to make the customer understand that leaving something out of this delivery phase doesn't mean they will never receive it. They may just have to wait a few months. Prioritisation is key. Use DSDM-style MoSCoW rules if you must (but don't be surprised if everything ends up as a "Must-Have"). You need to find a polite way of saying "You can have some of what you want now, or you can try to have it all and end up with nothing." If the customer can be made to understand this, then 90% of the battle is won.

However, what happens if your project really is suffering from slow development, and not just the illusion of slowness?

>> Page 4: Tackle the Problem Head-On

 

<< 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.