Home > Archive > Software Engineering > August 2006 > Re: Natural Forces, Engineering, and Software [LONG]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Natural Forces, Engineering, and Software [LONG]
|
|
| David Lightstone 2006-08-15, 8:00 am |
|
"S Perryman" <a@a.net> wrote in message
news:F4fEg.33496$PV5.280444@wagner.videotron.net...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:AP5Eg.808$q63.651@newssvr13.news.prodigy.com...
>
>
>
> Which is the problem I have with your comment.
> Especially the "outstanding" bit (which I'm not sure if it is sarcasm) .
>
> If I rephrase:
>
> When we talk about changing a system (underlying technologies, existing
> components etc) , what are the analytical consequences of that change ??
>
> On that basis, I am unclear if your comment relates from adding new system
> functions to an existing system to changing something for changes' sake.
>
Some background perhaps will be useful.
In 1995 I was working in Chicago, developing some software at motorola for
General Motors. Roughly every 4 - 5 w s we would get a new specification.
(the GM increment cycle duration, You could say in a very left-handed way
it was incremental test driven development, GM developed the validation
tests, motorola developed the hardware and code) The specification
reflected the integration problems discovered and "solved" (sometimes at our
expense) as well as the new "features" deemed to be needed. I think I was
spending 25 - 30 % of my time just trying to figure out what had changed
(change bars in the documents just were not enough, you actually did have to
read the document). The Outstanding!!!!! was serious, definitely not sarcasm
Anyhow, yes to evaluating analytic consequences, but also the managerial and
planning aspects. Conceptually evaluating the conseqences would include
schedule impact, but the impact is often hidden by some sort of
organizational boundary (ie not my budget, your budget, absorb the cost and
don't complain about it)
Second there is a phenomena of learning that needs to be considered. As
people become familiar with something they make discoveries and have
insights. These discoveries create new wishes and wants. (Here I am
attempting to address anticipation of needed changes.) The only example that
I can readily think of would be good inventory system (note no control).
When the update cycle is long it really serves no purpose in developing a
production control system. It just tells you the extent of your stock. When
the update cycle is on the order of magnitude a few ws, you can begin to
think of using it in production planning. Having an inventory system, and
then discoverying bar code readers, might set off an insight (can we also
develop a quasi realtime control system, bar code to cash register to
inventory control to purchasing)
What happens when the discovery and insight occurs while the software /
system is being built (ie incremental and evolutionary development, you turn
over a version and suddenly lights start going on in peoples heads.) Wishes
and want get created all over the place, all in need of management. This is
change at its worst
>
> Regards,
> Steven Perryman
>
|
|
|
|
|