RE: The last-minute change

[Paul Hanson <PHanson -at- Quintrex -dot- com>]

> Rick Vantour <rvantour -at- mondenet -dot- com> described the dreaded last-minute
> change:
> 
	SteveFJong -at- aol -dot- com added:
	<snip>
> However, consider this same scenario from the larger context of a
> development organization. What does the last-minute change mean?
	<snip very valid list of consequences>

> Now, each of these consequences is bad; together they are Very Bad. 
	Definitely.

> An up-front design process also helps reduce down-stream surprises.
	Very true. I am not in favor of last minute changes: I agree
with you Steve. I'd like to give a very recent (less than an hour ago)
example: I have spent all morning, and will be spending most of the
afternoon, massaging an important document today for internal review
tomorrow. I understand the content of this document and I know what the
functionality it describes will do to our clients' data: hose it up, if
they're not careful. <To AP: I know my subject and am working on the
content more than the formatting or fretting that I, as the TW, wasn't
the original author, which is supposed to be the process around here>
<grin>

	The original author of the doc I'm massaging came up and said
that the programmer just had a great idea. In the context of the
functionality, yes, it is a definite great idea. It's a definite "Why
didn't we think of that before?" solution to a big problem. It will
probably make our clients' headaches a bit duller instead of a sharp
pain. 

	I guess my point is: good ideas are not restricted by timing.
There *was* a lot of planning for this project and the original author
and I just looked at each other in disbelief that this idea hadn't
occurred to us before.

	Paul