>>>> Two years is not that long for a new software project.
>>>
[quoted text clipped - 20 lines]
> prototypes and complete rewrites in the coding phase, at least sometimes
> and at least at first.
> "Two weeks" is a known fallacy for time estimates in project management,
> but laymen might not understand that. It might be good to play to that
> two week event horizon.
You are correct. Actually, I was talking at cross purposes to your points, so
let me correct myself.
When I proposed two weeks for something to call a "product", I was not
referring to any kind of finished work at all. I have directly experienced
well-managed projects where requirements gathering was done via a tool that
directly captured screen ideas as executable interfaces, with no real
behaviors or data behind them. In one notable case, we spent three months
solid in this way before deciding we had the right screen flow. Our first
crude attempts were in place within two weeks, and took heavy criticism.
At all times, we had a document person keep the user manual up to date with
screenshots, and proposed functional requirements for the interface and its
underlying logic. Over three months the changes from one meeting to the next
became smaller. Our meetings were daily, at least three times a week with a
subject matter expert who understood the needs and psychology of the people
who would operate the product from day to day. The finished product was done
in about six months, and was virtually bug free. The major consulting firm to
whom I was contracted got much praise for the result from their large-scale
client.
In fact I am a strong proponent of thorough requirements gathering up front,
participating deeply with the client on an ontological and linguistic level.
Capture the requirements in as realistic a prototype as possible, meaning in
running code that people can see on their computers. Spend a long time
getting the requirements right. Keep the programmers responsible for feeding
every darn change, no matter how tiny, through version control and
notification to the documentation team no less frequently than daily. Use
integrated build-and-test cycles.
Certainly a full-fledged, highly complex system can take up to two years to
build out, but it can still be with staged, evolutionary, live prototypes from
the get-go. This has the added advantage of increasing reportable milestones,
objectively stated, with fine granularity. Project management is actually
facilitated.
I do agree with the original advice offered to the OP, that one must plan
one's business for at least a two-year growth cycle, and prepare funding
appropriately. I additionally propose that certain development methodologies
lend themselves to astonishingly rapid development and satisfyingly complete
visibility during that well-funded, extended business cycle.

Signature
Lew
Mark Space - 28 Apr 2008 00:17 GMT
> At all times, we had a document person keep the user manual up to date
> with screenshots, and proposed functional requirements for the interface
[quoted text clipped - 3 lines]
> virtually bug free. The major consulting firm to whom I was contracted
> got much praise for the result from their large-scale client.
Very interesting... I'm curious. Was that 6 months total, or 3 months +
6 months.
Here's why I'm curious. I'm re-reading Brooks after advising tenxian he
should do so. Fred Brooks writes:
"For some years I have been successfully using the following rule of
thumb for scheduling a software task:
" 1/3 planning
" 1/6 coding
" 1/4 component test and [...]
" 1/4 system test..."
So if your projects was 3+6 months, you nailed Fred Brooks' rule of
thumb. If not, I'm wondering where automatic code generation improved
things and which phases. :)
(Probably at least half the coding and half the unit test ("component
test") was done during the design as part of automatic code generation,
would be my guess.)
Lew - 28 Apr 2008 00:54 GMT
> Very interesting... I'm curious. Was that 6 months total, or 3 months +
> 6 months.
Six months total.
> Here's why I'm curious. I'm re-reading Brooks after advising tenxian he
> should do so. Fred Brooks writes:
[quoted text clipped - 10 lines]
> thumb. If not, I'm wondering where automatic code generation improved
> things and which phases. :)
We didn't use automatic code generation. It was all point-drag-and-drop, and
typing in various titles and other attributes.
Actually, there was a follow-on project for another six months.
> (Probably at least half the coding and half the unit test ("component
> test") was done during the design as part of automatic code generation,
> would be my guess.)
Again, it wasn't automatic, it was manual.

Signature
Lew