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

A Developers' Guide to ROI

<< Rule 2

RULE 3: Always try to deliver the biggest revenue creating item within a 3 month period.

Always try to deliver the biggest revenue creating or cost cutting piece of software within a 3 month period -- even if the software is a only partial solution.

Delivering software with little functionality quickly brings its own challenges. Users have been told for a long time to accept long delays before getting functionally rich applications. Users will need to change their mindsets to one of accepting a little and giving feedback immediately.

Getting a release out quickly also places a more immediate requirement on the support and administrative function in a project. Many projects leave this aspect of a project to the last minute. ROI aware projects need to design for, and partner with, support and administration right up front in a project. Sometimes ordering and installing equipment takes a couple of months.

Delivering quickly also means designing a scalable infrastructure. This means that an infrastructure capable of supporting the initial functionality should be developed very quickly. This often means using an out of the box infrastructure or a low performance infrastructure, behind interfaces that can be scaled up at a later date.

In fact this it's not quite as simple. Shorter development phases generally mean more bodies, and more bodies mean more cost and worse communication. In other words efficiency and scalability is a big issue in the development phase of a project.

Programmers don't often think about their efficiency and scalability during the development phase in the same way that they worry about the efficiency and scalability of their software during the run time phase.


>> RULE 4: Design your software so that development, as well as runtime, is quick and scalable.

Talkback:

Post a new message

Message Index:

good points
Keith Ray keithray at mac dot com

The Messages:
good points
Interesting thing mentioned on

http://www.martinfowler.com/articles/xp2002.html

- all 50 states have to implement a child-welfare tracking system, giving us the opportunity to see the "same" system implemented 50 times.

In Florida, a team of 100 people expected to deliver their implementation of this system in 8 years [starting 1990], though it is now to expected to deliver after 15 years [2005]. The budget is of course around $140 million over the original estimate of $32.

In Minnesota, a team of 10 people implemented their system in less than 2 years [starting 1999], using 10 people. Total cost $1.1 million.

These systems have the same federal requirements, but Minnesota probably focused on the "essential" requirements.

quote:

The comparison is a startling illustration of Chet Hendrickson's statement that "inside every large system there's a small system trying to get out".

Keith Ray keithray at mac dot com

Tue Jul 09 01:10:12 BST 2002

Post a new message

 

<< 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-2007 Matt Stephens. ALL RIGHTS RESERVED.