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 4

RULE 5: Build business softwalls that are architecture neutral.

A softwall is a major business interface in your application that shields technology either side of it. A softwall is an interface based on your business APIs. A softwall allows you to measure efficiency and achieve scalability in both the development and run time phase of a project.

Knowing the set of technical interfaces and business interfaces makes it possible to measure the efficiency of the project as the ratio of business interface to the codebase.

With code automation tools that created a complete system, the efficiency of the software process can be measured as 1:1. Using a code automation tool called JGenerator, we created an EJB application based on the Microsoft Northwind database; the codebase weighed in at 1.5Mb of source code based on a tiny 15K business properties file. This meant if the code was created by hand the efficiency ratio would have been 1:100, not very productive.

Building softwalls into your software is also important to enable your software to become scalable. Because the technology on either side of the softwall is unaware of each others' technology, it can be swapped to a more powerful technology with greater ease.

Investing capital in a project is not just about hardware and software, it's also about people. From an accountants' perspective, developers can be viewed as both assets and liabilities. If a project is going to be profitable and cash flows are available then it makes sense to increase the developers on a project until the ROI drops to an unacceptable level.


>> RULE 6: Employ a mix of permanent and contract staff on a project.

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.