FPGA Central

Fred Marshall wrote:

...

> You should have a process to prevent changes. Design freezes are a way to
> do this. This avoids bringing in the latest and greatest idea and perhaps
> even doing that again and again and again..... Then you should probably
> have a higher-level process to embrace great ideas for change.

I'm sorry, Fred, but that doesn't fly most of the time. Not only with
electronic design, but with "simpler and more straightforward" (hah!)
projects like bridges and buildings. As the chairman of the construction
committee during the building of a regional sewerage installation that
included a main plant, two satellite plants, three pumping stations, and
over 40 miles of trunk line, I can tell you than no piece of the project
was finished without change orders. The Mercury space capsules' audio
amplifiers were changed twice after the design was thought to be final.
First, to replace power transistors to increase allowable dissipation,
then to correct the near disaster caused by the change. When you go to
the market and discover that some ingredients are unavailable, you
substitute other ingredients or change the recipe.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins skrev:
> Fred Marshall wrote:
>
> ...
>
> > You should have a process to prevent changes. Design freezes are a way to
> > do this. This avoids bringing in the latest and greatest idea and perhaps
> > even doing that again and again and again..... Then you should probably
> > have a higher-level process to embrace great ideas for change.
>
> I'm sorry, Fred, but that doesn't fly most of the time. Not only with
> electronic design, but with "simpler and more straightforward" (hah!)
> projects like bridges and buildings. As the chairman of the construction
> committee during the building of a regional sewerage installation that
> included a main plant, two satellite plants, three pumping stations, and
> over 40 miles of trunk line, I can tell you than no piece of the project
> was finished without change orders. The Mercury space capsules' audio
> amplifiers were changed twice after the design was thought to be final.
> First, to replace power transistors to increase allowable dissipation,
> then to correct the near disaster caused by the change. When you go to
> the market and discover that some ingredients are unavailable, you
> substitute other ingredients or change the recipe.

Eh, Jerry... do you and Fred talk about the same things? I interpret
Fred's post such that he talks about freezing the *design*. Freezing
the design still leaves the freedom to change the *implementation*,
which, for some reason, I believe you are discussing.

To put it in a DSP context, the major design decision is to decide
whether to use a FIR filter or an IIR filter, since this is likely to
have some implications for what DSP chips can be used. Having chosen
the IIR filter, the implementation could be based on a Butterworth or
Chebyshev analog prototype or some optimized discrete-time design.
It could be a direct-form I or II, depending on whatever suits the
application. Yes, I know, the example is perhaps a bit far-fetched
but I hope you see my point. Freezing the decision to use IIR
filters still allows implementation details like filter orders and
filter coefficients to be changed, for yet some time.

Rune

Rune Allnor wrote:
>
> Jerry Avins skrev:
>
>>Fred Marshall wrote:
>>
>> ...
>>
>>
>>>You should have a process to prevent changes. Design freezes are a way to
>>>do this. This avoids bringing in the latest and greatest idea and perhaps
>>>even doing that again and again and again..... Then you should probably
>>>have a higher-level process to embrace great ideas for change.
>>
>>I'm sorry, Fred, but that doesn't fly most of the time. Not only with
>>electronic design, but with "simpler and more straightforward" (hah!)
>>projects like bridges and buildings. As the chairman of the construction
>>committee during the building of a regional sewerage installation that
>>included a main plant, two satellite plants, three pumping stations, and
>>over 40 miles of trunk line, I can tell you than no piece of the project
>>was finished without change orders. The Mercury space capsules' audio
>>amplifiers were changed twice after the design was thought to be final.
>>First, to replace power transistors to increase allowable dissipation,
>>then to correct the near disaster caused by the change. When you go to
>>the market and discover that some ingredients are unavailable, you
>>substitute other ingredients or change the recipe.
>
>
> Eh, Jerry... do you and Fred talk about the same things? I interpret
> Fred's post such that he talks about freezing the *design*. Freezing
> the design still leaves the freedom to change the *implementation*,
> which, for some reason, I believe you are discussing.
>
> To put it in a DSP context, the major design decision is to decide
> whether to use a FIR filter or an IIR filter, since this is likely to
> have some implications for what DSP chips can be used. Having chosen
> the IIR filter, the implementation could be based on a Butterworth or
> Chebyshev analog prototype or some optimized discrete-time design.
> It could be a direct-form I or II, depending on whatever suits the
> application. Yes, I know, the example is perhaps a bit far-fetched
> but I hope you see my point. Freezing the decision to use IIR
> filters still allows implementation details like filter orders and
> filter coefficients to be changed, for yet some time.

That's well put. How would you classify adding the two satellite plants
to the sewerage system? Originally, the system was designed with one
plant, and pipelines to it from all participating communities. One
administration blocked the two lines from the upstream communities,
forcing the Sewerage Authority to build the satellite plants. The
pipeline plans were scrapped, and we considered reducing the size of the
main plant. Is that a change of implementation, or of plans?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

"Rune Allnor" <[email protected]> wrote in message
news:[email protected] oups.com...
> Eh, Jerry... do you and Fred talk about the same things? I interpret
> Fred's post such that he talks about freezing the *design*. Freezing
> the design still leaves the freedom to change the *implementation*,
> which, for some reason, I believe you are discussing.

What we call "implementation" in the software business is just the easy or
less significant part of the design process. There is no sharp distinction.
Design is everything between inception and mass production.

> [ for example ] Freezing the decision to use IIR
> filters still allows implementation details like filter orders and
> filter coefficients to be changed, for yet some time.

Yes, and with this example you can see how the world outside of engineering
would have no knowledge of or respect for the distinction you make between
"design decisions" and "implementation details". That's because the
distinction is artificial -- it is the process of design that determines
what will be easy to change later and what will not. A good designer should
avoid tying excessive investments of time or money to decisions which are
likely to be undone later.

--
Matt

"A good designer should
avoid tying excessive investments of time or money to decisions which
are
likely to be undone later. "

In other words designers have to be fortune tellers.

"Jerry Avins" <[email protected]> wrote in message
news:[email protected]..
> Fred Marshall wrote:
>
> ...
>
>> You should have a process to prevent changes. Design freezes are a way
>> to do this. This avoids bringing in the latest and greatest idea and
>> perhaps even doing that again and again and again..... Then you should
>> probably have a higher-level process to embrace great ideas for change.
>
> I'm sorry, Fred, but that doesn't fly most of the time. Not only with
> electronic design, but with "simpler and more straightforward" (hah!)
> projects like bridges and buildings. As the chairman of the construction
> committee during the building of a regional sewerage installation that
> included a main plant, two satellite plants, three pumping stations, and
> over 40 miles of trunk line, I can tell you than no piece of the project
> was finished without change orders. The Mercury space capsules' audio
> amplifiers were changed twice after the design was thought to be final.
> First, to replace power transistors to increase allowable dissipation,
> then to correct the near disaster caused by the change. When you go to the
> market and discover that some ingredients are unavailable, you substitute
> other ingredients or change the recipe.

Jerry,

You were the chairman of the construction committee.
You were in control of the "higher level process to embrace great ideas for
change".
So, you changed things when necessary.
I don't see any problem with that or any contradiction with what I said.

In the context of what I said first: "better is the enemy of good enough".
That's when you need to freeze. For example:

We have a filter requirement. We design a FIR filter that works fine. It
has been implemented and tested. Then somebody figures out that a few
memory locations can be saved and we can still meet the requirement with an
IIR filter. So, with no design controls in place, the designer decides to
re-design the filter. Hey, it's fun and the experience gained is great.
Except now the impulse response is longer and that affects parts of the
system that had already been tested and the difference shows up rather late
in the development cycle and the filter designer has gone and the FIR filter
is forgotten and people are wondering how to get back to what worked and
....... you get the idea.

I didn't say: "don't allow any changes". I said that freezing is good *and*
overruling the freeze process can also be good. I'm sure that many of us
have had experiences where things were controlled by idiots. That makes any
good idea look bad. It doesn't invalidate the good ideas. I think we're
back to Rune's suggestion that there has to be good craftsmanship. That
applies in management too.

Here is a very positive story about design freeze:

I took over a group that was building a rather complex board - of a design
that had never been done before.
Their plan was to build the board and then "spin" it - i.e. do a second pass
at the layout because they figured there would be changes, errors, things
that didn't work, etc. The second pass added precious months to the
schedule.

So, I told them that we had to get first-pass success and that's what we had
to plan on.
They had to get it right the first time.

The idea isn't exactly the same as design freeze but pretty close. The
design was "going to be frozen" in their minds so they had to get it right
the first time.

They did it. Interesting, eh?

Fred

Jerry Avins skrev:
> Rune Allnor wrote:
> >
> > Jerry Avins skrev:
> >
> >>Fred Marshall wrote:
> >>
> >> ...
> >>
> >>
> >>>You should have a process to prevent changes. Design freezes are a way to
> >>>do this. This avoids bringing in the latest and greatest idea and perhaps
> >>>even doing that again and again and again..... Then you should probably
> >>>have a higher-level process to embrace great ideas for change.
> >>
> >>I'm sorry, Fred, but that doesn't fly most of the time. Not only with
> >>electronic design, but with "simpler and more straightforward" (hah!)
> >>projects like bridges and buildings. As the chairman of the construction
> >>committee during the building of a regional sewerage installation that
> >>included a main plant, two satellite plants, three pumping stations, and
> >>over 40 miles of trunk line, I can tell you than no piece of the project
> >>was finished without change orders. The Mercury space capsules' audio
> >>amplifiers were changed twice after the design was thought to be final.
> >>First, to replace power transistors to increase allowable dissipation,
> >>then to correct the near disaster caused by the change. When you go to
> >>the market and discover that some ingredients are unavailable, you
> >>substitute other ingredients or change the recipe.
> >
> >
> > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > Fred's post such that he talks about freezing the *design*. Freezing
> > the design still leaves the freedom to change the *implementation*,
> > which, for some reason, I believe you are discussing.
> >
> > To put it in a DSP context, the major design decision is to decide
> > whether to use a FIR filter or an IIR filter, since this is likely to
> > have some implications for what DSP chips can be used. Having chosen
> > the IIR filter, the implementation could be based on a Butterworth or
> > Chebyshev analog prototype or some optimized discrete-time design.
> > It could be a direct-form I or II, depending on whatever suits the
> > application. Yes, I know, the example is perhaps a bit far-fetched
> > but I hope you see my point. Freezing the decision to use IIR
> > filters still allows implementation details like filter orders and
> > filter coefficients to be changed, for yet some time.
>
> That's well put. How would you classify adding the two satellite plants
> to the sewerage system? Originally, the system was designed with one
> plant, and pipelines to it from all participating communities. One
> administration blocked the two lines from the upstream communities,
> forcing the Sewerage Authority to build the satellite plants. The
> pipeline plans were scrapped, and we considered reducing the size of the
> main plant. Is that a change of implementation, or of plans?

That's certainly a change of plans, what I am concerned.

Rune

Matt Timmermans skrev:
> "Rune Allnor" <[email protected]> wrote in message
> news:[email protected] oups.com...
> > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > Fred's post such that he talks about freezing the *design*. Freezing
> > the design still leaves the freedom to change the *implementation*,
> > which, for some reason, I believe you are discussing.
>
> What we call "implementation" in the software business is just the easy or
> less significant part of the design process. There is no sharp distinction.

I know.

> Design is everything between inception and mass production.

To me, "design" si the intellectual effort of concocting (choosing) a
way of meeting the goals. "Implementation" is about putting the design

into practice.

> > [ for example ] Freezing the decision to use IIR
> > filters still allows implementation details like filter orders and
> > filter coefficients to be changed, for yet some time.
>
> Yes, and with this example you can see how the world outside of engineering
> would have no knowledge of or respect for the distinction you make between
> "design decisions" and "implementation details".

Which is why I made the point that project managment must be recruited
amongst the engineers.

> That's because the
> distinction is artificial --

Sorry, I don't agree. Again, "design" is about choosing what
algorithms to use, how to organize the program, getting a block
diagram representation etc. It's the intellectual effort invested
in making a program or system. "Implementation" is about getting
a software function or piece of machinery to perform a pre-determined
action. Which could involve an excercise in design on its own.

I don't know if you have experience with matlab. It's a computer
system for numerical computing, that allows just about anything
in software computing: Scripts, Structured programming, Object
oriented programming, GUIs, typed programming, non-typed programming...

the one thing I have not been able to do with matlab, is to implement
GOTO statements. Students who have matlab as their computing experience
(as opposed to C/C++, pascal, Fortran...) don't have any concepts of
program design. They find a way of getting something done, usually a
severe mixture of all concepts above, and do it. Program maintenance
is impossible, even understanding the code can be a nightmare.
That's before whe start speaking of how matlab handles trivial
control statements and conditionals.

Regardless of matlab, the scientists don't have much grasp of design,
they just implement. One infamous example was an ocean acoustics
propagation model, that easily could use hours on one computation.
There was a graphical interface added on that program, to plot the
results. The guy who implemented the code did not separate the two,
so you specified the visualization along with the physics of the
simulation. If you after 2 - 10 hours found that the data selection
was a bit "off", you had to do the whole 2 - 10 hour simulation
again before seeing the new data selection. The distinction was
made in later versions of the program.

This guy knew his implementation. He was the first to get this
particular sort of simulation to work, and used all sorts of tricks,
both algorithms and data structures, to get a numerically stable
simulation code. But he knew squat about design.

Similarly, I had a young engineer help me make a driver for some
arcane tape driver. The engineer knew his implementations - he got
the thing to work - but he had no concepts of design. He was not
concious about the great speed difference between the computer and
the tape drive, he did not use I/O buffers so his program read
gigabytes of data from the tape, on a byte-by-byte basis. It took
hours to read the tapes, where minutes ought to have sufficed.

"Design" is an independent skill that needs a conscious effort to
be learned. "Implementation" is actually handling the kit, be it
the computer or the lathe.

Perhaps "design" is the "strategy" and "implementation" the "tactics".

> it is the process of design that determines
> what will be easy to change later and what will not.

As user of a software program, you don't necessarily acknowledge the
difference between a structured design of the source code, or an
Object Oriented design of the source code. OO was so new when I went
to universirty, that only the specialized computer science guys got
courses that covered it. We, the engineers, could learn it on our
own, but few did: "OO is so hard to wrap one's mind around, and we
don't need it for the small projects we program".

I did make the effort, and now I hardly do anything that isn't Object
Oriented in one way or another. In this case, the difference between
the two designs are basicaly that they are two different states of
mind.
The implementations "hardly" change at all: A little bit of voodoo with

function declarations, some added restrictions on the class
declarations, and that's it.

Deciding whether to go OO or not, is a major design desicion. In my
world of scientific computing, it will have very little impact on the
"scientifically important" stuff, which is the numerics. OO could
make all the difference with respect to communication with other
programs, extensions of functionality, etc.

> A good designer should
> avoid tying excessive investments of time or money to decisions which are
> likely to be undone later.

Rune

steve wrote:
> "A good designer should
> avoid tying excessive investments of time or money to decisions which
> are
> likely to be undone later. "
>
> In other words designers have to be fortune tellers.

They certainly do. Most successful projects are those where the decision
maker(s) could adequately forsee where enough flexibility had to be
incorporated to cope with the most likely changes in requirements.

Add flexibility everywhere in a project and the cost, timescale, hassle,
risk, etc. go through the roof. Provide no flexibility are the 100%
absolutely certain changes in need that will occur over the project's
life will make it obsolete before completion.

Regards,
Steve

Rune Allnor skrev:
> Jerry Avins skrev:
> > Rune Allnor wrote:
> > >
> > > Jerry Avins skrev:
> > >
> > >>Fred Marshall wrote:
> > >>
> > >> ...
> > >>
> > >>
> > >>>You should have a process to prevent changes. Design freezes are a way to
> > >>>do this. This avoids bringing in the latest and greatest idea and perhaps
> > >>>even doing that again and again and again..... Then you should probably
> > >>>have a higher-level process to embrace great ideas for change.
> > >>
> > >>I'm sorry, Fred, but that doesn't fly most of the time. Not only with
> > >>electronic design, but with "simpler and more straightforward" (hah!)
> > >>projects like bridges and buildings. As the chairman of the construction
> > >>committee during the building of a regional sewerage installation that
> > >>included a main plant, two satellite plants, three pumping stations, and
> > >>over 40 miles of trunk line, I can tell you than no piece of the project
> > >>was finished without change orders. The Mercury space capsules' audio
> > >>amplifiers were changed twice after the design was thought to be final.
> > >>First, to replace power transistors to increase allowable dissipation,
> > >>then to correct the near disaster caused by the change. When you go to
> > >>the market and discover that some ingredients are unavailable, you
> > >>substitute other ingredients or change the recipe.
> > >
> > >
> > > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > > Fred's post such that he talks about freezing the *design*. Freezing
> > > the design still leaves the freedom to change the *implementation*,
> > > which, for some reason, I believe you are discussing.
> > >
> > > To put it in a DSP context, the major design decision is to decide
> > > whether to use a FIR filter or an IIR filter, since this is likely to
> > > have some implications for what DSP chips can be used. Having chosen
> > > the IIR filter, the implementation could be based on a Butterworth or
> > > Chebyshev analog prototype or some optimized discrete-time design.
> > > It could be a direct-form I or II, depending on whatever suits the
> > > application. Yes, I know, the example is perhaps a bit far-fetched
> > > but I hope you see my point. Freezing the decision to use IIR
> > > filters still allows implementation details like filter orders and
> > > filter coefficients to be changed, for yet some time.
> >
> > That's well put. How would you classify adding the two satellite plants
> > to the sewerage system? Originally, the system was designed with one
> > plant, and pipelines to it from all participating communities. One
> > administration blocked the two lines from the upstream communities,
> > forcing the Sewerage Authority to build the satellite plants. The
> > pipeline plans were scrapped, and we considered reducing the size of the
> > main plant. Is that a change of implementation, or of plans?
>
> That's certainly a change of plans, what I am concerned.
>
> Rune

My answer still stands, but I try not to use the word "plan" in this
discussion. In my mind, a "plan" is a list of things that need be done
in order to implement some system or strategy, or otherwise achieve a
goal. If circumstances change, the plan must change. Here,
"circumstances"
include both "implementation" and "design".

Your original goal, make a sewerage facility to serve the community,
was still valid. The feasible way to achieve it changed. Hence your
change of implementation and of plans.

When I talk of "changing goals" or "changing designs", I mean "changing

the purpose" of the activity. It would be a "changed design" if you
started
out to build a sewerage facility but ended up building, say, a parking
lot
or a mall.

I like to watch BBC's "Top Gear", a weekly TV show where new cars
are reviewed, tested and commented on. The hosts are very clear in
their opinions about what is good and what is bad. Particularly
high-profile brands and models (Ferraris, Porches, BMWs,...) are
put through their paces in the show.

With these types of cars, one main reason for giving bad reviews is
often the purpose of the car: "The designers did not decide what kind
of car this would be. They wanted this to be a sports car. They wanted
this to be a muscle car. They wanted this to be a road cruiser. It is
none of the above".

Of course, when the purpose of the car is undisputed, the hosts go
on to explain, in the most English way, why the purpose was not
achieved.

Rune

Rune Allnor wrote:
>
> Rune Allnor skrev:
>
>>Jerry Avins skrev:


...

>>>That's well put. How would you classify adding the two satellite plants
>>>to the sewerage system? Originally, the system was designed with one
>>>plant, and pipelines to it from all participating communities. One
>>>administration blocked the two lines from the upstream communities,
>>>forcing the Sewerage Authority to build the satellite plants. The
>>>pipeline plans were scrapped, and we considered reducing the size of the
>>>main plant. Is that a change of implementation, or of plans?
>>
>>That's certainly a change of plans, what I am concerned.
>>
>>Rune
>
>
> My answer still stands, but I try not to use the word "plan" in this
> discussion. In my mind, a "plan" is a list of things that need be done
> in order to implement some system or strategy, or otherwise achieve a
> goal. If circumstances change, the plan must change. Here,
> "circumstances"
> include both "implementation" and "design".
>
> Your original goal, make a sewerage facility to serve the community,
> was still valid. The feasible way to achieve it changed. Hence your
> change of implementation and of plans.
>
> When I talk of "changing goals" or "changing designs", I mean "changing
>
> the purpose" of the activity. It would be a "changed design" if you
> started
> out to build a sewerage facility but ended up building, say, a parking
> lot
> or a mall.
>
> I like to watch BBC's "Top Gear", a weekly TV show where new cars
> are reviewed, tested and commented on. The hosts are very clear in
> their opinions about what is good and what is bad. Particularly
> high-profile brands and models (Ferraris, Porches, BMWs,...) are
> put through their paces in the show.
>
> With these types of cars, one main reason for giving bad reviews is
> often the purpose of the car: "The designers did not decide what kind
> of car this would be. They wanted this to be a sports car. They wanted
> this to be a muscle car. They wanted this to be a road cruiser. It is
> none of the above".
>
> Of course, when the purpose of the car is undisputed, the hosts go
> on to explain, in the most English way, why the purpose was not
> achieved.

You made my point, I think. "One plant downstream" can be either a plan
or an implementation, depending on how long a view one takes. We had
other design goals, not stated above. Among them, we wanted to avoid
despoiling the countryside we live in. The main plant discharges into a
river. When the inflow from heavy rains degrades the quality of the
effluent, the river becomes a torrent that can accommodate heavy BOD*
loading. Where before, one community's outfall caused periodic fish
kills, now fish congregate just downstream of our much larger plant's
discharge pipe. Not only is dissolved oxygen higher there, but the water
is clearer than upstream. It's a great place to fish.

The upstream plants pose a different problem. Both discharge into the
headwaters of streams that, without their flow, would be dry for weeks
at a time. Before the plants were built, fish and other aquatic life
would ride out the dry spells in pools in the stream bed, and many would
survive. (Some of the pools are spring fed.) Since they began operation,
each upstream plant discharges about 0.3 million gallons a day of
treated sewage into each stream. The streams never run dry. Clearly, for
weeks at a time, there is nothing in the stream but sewage, and sewage
is a major component at all times. We didn't want that responsibility.

_That wasn't the original plan._ But the original goal gas been met:
there have been no fish die-offs in the 25 years that the plants have
been in operation. Kids swim and wade without harm; animals drink. _But
we spend a lot more to treat upstream sewage upstream_ than it would
have cost to send it downstream and treat it there. When the downstream
plant operates normally, as it does an average of 363 days a year, its
effluent tests purer than most bottled water. http://www.sbrsa.org/

Jerry
___________________________
* Biological oxygen demand
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

steve wrote:
> "A good designer should
> avoid tying excessive investments of time or money to decisions which
> are
> likely to be undone later. "
>
> In other words designers have to be fortune tellers.

Not all forecasting is prognostication.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Fred Marshall wrote:
> "Jerry Avins" <[email protected]> wrote in message
> news:[email protected]..
>
>>Fred Marshall wrote:
>>
>> ...
>>
>>
>>>You should have a process to prevent changes. Design freezes are a way
>>>to do this. This avoids bringing in the latest and greatest idea and
>>>perhaps even doing that again and again and again..... Then you should
>>>probably have a higher-level process to embrace great ideas for change.
>>
>>I'm sorry, Fred, but that doesn't fly most of the time. Not only with
>>electronic design, but with "simpler and more straightforward" (hah!)
>>projects like bridges and buildings. As the chairman of the construction
>>committee during the building of a regional sewerage installation that
>>included a main plant, two satellite plants, three pumping stations, and
>>over 40 miles of trunk line, I can tell you than no piece of the project
>>was finished without change orders. The Mercury space capsules' audio
>>amplifiers were changed twice after the design was thought to be final.
>>First, to replace power transistors to increase allowable dissipation,
>>then to correct the near disaster caused by the change. When you go to the
>>market and discover that some ingredients are unavailable, you substitute
>>other ingredients or change the recipe.
>
>
> Jerry,
>
> You were the chairman of the construction committee.
> You were in control of the "higher level process to embrace great ideas for
> change".
> So, you changed things when necessary.
> I don't see any problem with that or any contradiction with what I said.
>
> In the context of what I said first: "better is the enemy of good enough".
> That's when you need to freeze. For example:
>
> We have a filter requirement. We design a FIR filter that works fine. It
> has been implemented and tested. Then somebody figures out that a few
> memory locations can be saved and we can still meet the requirement with an
> IIR filter. So, with no design controls in place, the designer decides to
> re-design the filter. Hey, it's fun and the experience gained is great.
> Except now the impulse response is longer and that affects parts of the
> system that had already been tested and the difference shows up rather late
> in the development cycle and the filter designer has gone and the FIR filter
> is forgotten and people are wondering how to get back to what worked and
> ...... you get the idea.
>
> I didn't say: "don't allow any changes". I said that freezing is good *and*
> overruling the freeze process can also be good. I'm sure that many of us
> have had experiences where things were controlled by idiots. That makes any
> good idea look bad. It doesn't invalidate the good ideas. I think we're
> back to Rune's suggestion that there has to be good craftsmanship. That
> applies in management too.
>
> Here is a very positive story about design freeze:
>
> I took over a group that was building a rather complex board - of a design
> that had never been done before.
> Their plan was to build the board and then "spin" it - i.e. do a second pass
> at the layout because they figured there would be changes, errors, things
> that didn't work, etc. The second pass added precious months to the
> schedule.
>
> So, I told them that we had to get first-pass success and that's what we had
> to plan on.
> They had to get it right the first time.
>
> The idea isn't exactly the same as design freeze but pretty close. The
> design was "going to be frozen" in their minds so they had to get it right
> the first time.
>
> They did it. Interesting, eh?

We didn't appear to agree at first, but it seems we do. I don't
subscribe to "If it ain't broke, don't fix it", but to a related maxim:
"If you can see trouble coming, head it off." Another sewerage example:

The upstream plants, the ones where failure turns miles of scenic brook
into a sewage ditch, use a then-novel treatment scheme to make
super-clean effluent. The process uses partly submerged rotating disks
to achieve aeration and be a substrate for active bacteria. The supports
for these disks were to be bolted to both sides of the concrete trough
in which the sewage flows. I saw it going in, and questioned the wisdom
of bolting steel to concrete that way. Differential expansion might tend
to crack the concrete. Our consulting engineers had bought the patented
design and used it "out of the box". When I questioned its longevity, I
was reminded that prototypes had already been operating some four years
with no problem. I remembered something else, and asked, "Where are
they?" They were all in southern California, where the weather is quite
different from here, central New Jersey.

The bolts were already set into the concrete; what to do? The original
plan was bolting each end with a half-inch pad under it. We bolted one
end with its pad, and left a half-inch gap with no nut on the other end.
That end is supported by the bolt, but not longitudinally constrained by
it. Despite out harsher winters, there has been no cracking yet. But the
California installations weren't "broke", so despite all subsequent
installations using my floating hangers, the old ones weren't fixed. At
least one original southern California trough is now patched.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

"Jerry Avins" <[email protected]> wrote in message
news:[email protected]..
> Fred Marshall wrote:
......................
>
> The bolts were already set into the concrete; what to do? The original
> plan was bolting each end with a half-inch pad under it. We bolted one end
> with its pad, and left a half-inch gap with no nut on the other end. That
> end is supported by the bolt, but not longitudinally constrained by it.
> Despite out harsher winters, there has been no cracking yet. But the
> California installations weren't "broke", so despite all subsequent
> installations using my floating hangers, the old ones weren't fixed. At
> least one original southern California trough is now patched.
>
> Jerry
> --

Jerry,

Well, you didn't have a working model in the context of your application.
But you also didn't *prove* that cracking would occur did you? (If you did
then OK - bear with me; I'm not suggesting that you didn't have a valid
concern).

What if it had been built for NJ and no failure occurred? And subsequently
the worry came up?
Should you change the implementation or not? Your example re: California is
perfect! The worry was apparently sufficiently justified that taking the
nuts off in California would have been the smart thing to do.

A lot depends on the change that's contemplated.
I once had a job solving problems on a system that was in production. The
idea was to solve the problem without introducing any additional parts. It
was a great challenge and fun to solve the problems with that constraint.
Very much like removing the nuts. Mind you, the solutions were changes -
but ones that had been asked for.

So, if all you had to do was remove some redundant nuts in order to make the
design "better" then by all means. These notions are more guidelines than
hard and fast rules. When the notions are stated in "shorthand" then maybe
they sound stricter. If you *must* make a change then who could argue? We
have not (thank goodness?) talked about change control - which is often more
about configuration management but can also be about making the decision to
change or not to change in a formalized manner. The idea about design
freeze is to enable getting into production without ruining all the testing
that has already been done. It's also about getting rid of the crazy "new
ideas" that some folks *never* stop coming up with, and curtailing those
participants who can never make a decision, so that there can be a
reasonable degree of stability. It's also about not paying for the changes
(risk, time and money) unless it's necessary.

If you have always worked with sensible people who always made the right
decisions and caused things to happen really well without a hitch then you
might think others are a little crazy to suggest some structure. But, if
you've worked with people who are always wanting to try the latest and
greatest stuff because having fun is more important than getting out the
product or if you've worked with people who can't make a decision or if
you're working with people who would make an unnecessary change (because
they had not weighed the cost and risk vs. the benefit - or because their
assessment is different than yours) then you would see the value in some
structure along those lines.

Sometimes "design freeze" is used to simply get people to make up their
minds, finish their work, etc.

Software is *so* easy to change. How many times has someone broken the
system with some little change? The software books are full of examples.
Of course, many of those examples are to make a technical point. But the
examples sure beg the question: "What if the change had not been made at
all? Would it have mattered - i.e. would the system still have performed
just fine?" That's more to the point. How many times did the change come
up because the programmer thought: "Well, I just figured it might be easier
to read the code if ...... "

I'm pretty sure we agree on most of this....

At the core this is more about decision making. Your folks decided to not
make changes in California. Were they driven to that decision because they
didn't want to spend the money? Or, were they driven to that decision by
blind allegiance to a "freeze" kind of rule? I'll bet it's the former and,
on a comparative basis, I agree with that being the driver even if we might
disagree in hindsight (or in foresight) with the decision they made.

Fred

Rune, I'd rather argue about practical matters instead of definitions, so
let me try it this way:

> Again, "design" is about choosing what
> algorithms to use, how to organize the program, getting a block
> diagram representation etc. It's the intellectual effort invested
> in making a program or system.

In my shop, unless I have to pass an audit, the products of all these
activities are mostly code. At the level you're describing, most of this
code is just interfaces, comments, and glue, but it is real code that
becomes part of the project. After all, it is code that really defines the
algorithms that get used, and the program organization, etc. The code will
be documented with block diagrams, overviews, various bits of UML, etc., in
order to communicate its gestalt more clearly, but most of the work here is
code.

I know that a lot of process-oriented folks think that there should be a
separate design phase that produces something other than code, but which is
actually a lot like code. In my experience, this is a bad idea. Rather
than turning much of the programming job into mere transcription, it's more
efficient to write your original ideas directly in the target language.
That way, your programmers can work on something more interesting, and you
don't need to rely on their secretarial skills to transcribe your thoughts
accurately. (Pssst. They don't *read* what you write. They just skim
through it.)

> "Implementation" is about getting
> a software function or piece of machinery to perform a pre-determined
> action.

I have a bit of trouble understanding what you mean by this. If you really
mean "a pre-determined action", then I know there are places where
programmers actually have jobs like this, but I swear that my shop will
never be one of them. Have you seen "Metropolis?" If you just mean
"fulfill some defined purpose", then you can see why I think that this is
the same task as above, but on a smaller scale. The product of this
activity is also code. It's just more isolated code that isn't reflected
throughout the system like the overall architectural components are. The
processes used for creating all this code, and the purpose of all this code,
is essentially the same. In all cases, the coder is defining the structure
and operation of software.

I know you may not agree with my way of thinking about this, so to see who
is more practically correct, perhaps we should see if we can find some sort
of phase transition near the middle of the software development process that
would justify your assignment of different labels to the pre-transition and
post-transition phases:

- Is there a point near the middle of development where schedules suddenly
become firm? In my experience, no, there usually isn't. Certainty
increases gradually and continually during development.

- Is there a point near the middle of development where feasibility suddenly
becomes proven? I have found that doubts about feasibility can only be
quelled by real implementations. It is a good idea to implement these
questionable parts of a project early, but because these aren't usually
isolated or architectural parts of the project, you can't just do them all
first.

- Is there a point near the middle of development when you can validate all
of your preceding assumptions with the customer? Again, in my experience,
there is not. If customers could look at a project in progress and really
determine whether or not it meets their needs, they wouldn't need you or me.

So, if you still think that there is a real, practical, division of
development into design and implementation phases, then when, oh when, does
it occur, and what are the practical consequences of reaching it?

--
Matt

"steve" <[email protected]> wrote in message
news:[email protected] oups.com...
> "A good designer should
> avoid tying excessive investments of time or money to decisions which
> are
> likely to be undone later. "
>
> In other words designers have to be fortune tellers.

Oh, yes, and they have to do it the same way real fortune tellers do -- by
understanding their customers.

--
Matt

Matt Timmermans wrote:
> "steve" <[email protected]> wrote in message
> news:[email protected] oups.com...
>
>>"A good designer should
>>avoid tying excessive investments of time or money to decisions which
>>are
>>likely to be undone later. "
>>
>>In other words designers have to be fortune tellers.
>
>
> Oh, yes, and they have to do it the same way real fortune tellers do -- by
> understanding their customers.

Yeah man!

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Matt Timmermans wrote:
> Rune, I'd rather argue about practical matters instead of definitions, so
> let me try it this way:
>
>
>>Again, "design" is about choosing what
>>algorithms to use, how to organize the program, getting a block
>>diagram representation etc. It's the intellectual effort invested
>>in making a program or system.
>
>
> In my shop, unless I have to pass an audit, the products of all these
> activities are mostly code. At the level you're describing, most of this
> code is just interfaces, comments, and glue, but it is real code that
> becomes part of the project. After all, it is code that really defines the
> algorithms that get used, and the program organization, etc. The code will
> be documented with block diagrams, overviews, various bits of UML, etc., in
> order to communicate its gestalt more clearly, but most of the work here is
> code.
>
> I know that a lot of process-oriented folks think that there should be a
> separate design phase that produces something other than code, but which is
> actually a lot like code. In my experience, this is a bad idea. Rather
> than turning much of the programming job into mere transcription, it's more
> efficient to write your original ideas directly in the target language.
> That way, your programmers can work on something more interesting, and you
> don't need to rely on their secretarial skills to transcribe your thoughts
> accurately. (Pssst. They don't *read* what you write. They just skim
> through it.)
>
>
>>"Implementation" is about getting
>>a software function or piece of machinery to perform a pre-determined
>>action.
>
>
> I have a bit of trouble understanding what you mean by this. If you really
> mean "a pre-determined action", then I know there are places where
> programmers actually have jobs like this, but I swear that my shop will
> never be one of them. Have you seen "Metropolis?" If you just mean
> "fulfill some defined purpose", then you can see why I think that this is
> the same task as above, but on a smaller scale. The product of this
> activity is also code. It's just more isolated code that isn't reflected
> throughout the system like the overall architectural components are. The
> processes used for creating all this code, and the purpose of all this code,
> is essentially the same. In all cases, the coder is defining the structure
> and operation of software.
>
> I know you may not agree with my way of thinking about this, so to see who
> is more practically correct, perhaps we should see if we can find some sort
> of phase transition near the middle of the software development process that
> would justify your assignment of different labels to the pre-transition and
> post-transition phases:
>
> - Is there a point near the middle of development where schedules suddenly
> become firm? In my experience, no, there usually isn't. Certainty
> increases gradually and continually during development.
>
> - Is there a point near the middle of development where feasibility suddenly
> becomes proven? I have found that doubts about feasibility can only be
> quelled by real implementations. It is a good idea to implement these
> questionable parts of a project early, but because these aren't usually
> isolated or architectural parts of the project, you can't just do them all
> first.
>
> - Is there a point near the middle of development when you can validate all
> of your preceding assumptions with the customer? Again, in my experience,
> there is not. If customers could look at a project in progress and really
> determine whether or not it meets their needs, they wouldn't need you or me.
>
> So, if you still think that there is a real, practical, division of
> development into design and implementation phases, then when, oh when, does
> it occur, and what are the practical consequences of reaching it?

Matt,

Before I write code, I want to know what it's supposed to do. When it's
for a client, I want to be very sure that the client knows it's supposed
to do. I did programming for hire for a time, sometimes moonlighting,
and for a while as part of my only professional activity. I learned from
other's bad experiences before I started to insist on a set of
specifications that would allow the client to prove that I didn't finish
the job, and allow me to prove that I did. Some clients didn't like to
be pinned down, and if I liked the job I would help to write the
document. I excepted as a requirements specification a users manual that
explained how to use every feature and described everything that a user
would see. If it was loose, I reserved (in writing) the right to fill in
the details as I thought reasonable, and to charge extra for changes. It
was a good policy, allowing me to keep friendships that I would
otherwise have lost. Once, it sort of backfired.

A friend of a friend asked me to code a personality profile program he
could use in his business. He had the algorithms and a general outline,
but no details. I asked for a spec to work to, saying that a user manual
would do. He said he'd get back to me when he was ready, we shook hands,
and I didn't hear from him until I got a check in the mail, about a
day's fee, a few months later. I phoned his office about the mistake and
asked if I should return the check or tear it up. He phoned back about
an hour later and told me that I had more than earned it.

He confessed that he had been frightened to put specs on paper because
they might not be reasonable to meet. So every time he wrote a coherent
subsection of the manual he coded it in BASIC to see if it was workable.
Most of the time it was, and when it wasn't -- GWBASIC is not a good
language for graphics -- he changed the manual. By the time he had the
specification, he had a working program. The check was for teaching him
how to get it right. I cashed it happily despite knowing that I had
talked myself out of a job.

The design part consists of deciding what the used will see and what he
must to. Coding comes after. Design can be a chapter at a time, or the
whole manual, but at every point along the way, you need a direction.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Matt Timmermans skrev:
> Rune, I'd rather argue about practical matters instead of definitions, so
> let me try it this way:
>
> > Again, "design" is about choosing what
> > algorithms to use, how to organize the program, getting a block
> > diagram representation etc. It's the intellectual effort invested
> > in making a program or system.
>
> In my shop, unless I have to pass an audit, the products of all these
> activities are mostly code. At the level you're describing, most of this
> code is just interfaces, comments, and glue, but it is real code that
> becomes part of the project. After all, it is code that really defines the
> algorithms that get used, and the program organization, etc. The code will
> be documented with block diagrams, overviews, various bits of UML, etc., in
> order to communicate its gestalt more clearly, but most of the work here is
> code.

OK. No problems here.

> I know that a lot of process-oriented folks think that there should be a
> separate design phase that produces something other than code, but which is
> actually a lot like code. In my experience, this is a bad idea.

I know what you mean, although I don't have enough experience to
actually fill in. My experience are with projects taking one or
to people to code (the "one" being me) where somebody have some
expectations to the program. I don't know how you think of it,
but I prefer to spend a lot of the time talking with the customer
so I know what he expects, and prehaps reaches an agreement on how
to do things. When I know the "big picture", I may be able to prepare
an extension later on, in a follow-up project, even if we are talking
merely basic stuff at the first delivery.

> Rather
> than turning much of the programming job into mere transcription, it's more
> efficient to write your original ideas directly in the target language.

That's usually why projects blow up, in my experience... the first,
"naive" thoughts may have some essnce of usefulness in them, but
usually
I have to start over from scratch pretty soon, if I start out that way.

> That way, your programmers can work on something more interesting, and you
> don't need to rely on their secretarial skills to transcribe your thoughts
> accurately. (Pssst. They don't *read* what you write. They just skim
> through it.)

What is wrong with having the programmers chime in when discussing
the overall project? Not necessarily with the customers, but at least
in-house? With a bit of luck, they come up with some good ideas, and
it might perhaps even generate a bit of interest with them.

> > "Implementation" is about getting
> > a software function or piece of machinery to perform a pre-determined
> > action.
>
> I have a bit of trouble understanding what you mean by this. If you really
> mean "a pre-determined action", then I know there are places where
> programmers actually have jobs like this, but I swear that my shop will
> never be one of them.

I mean that once you sit down to actually write the code, you should be

very clear about what that code is supposed to do. I did not say that
somebody *else* than yourself/the coder should come up with the plan,
but the plan ought to be clear beforehand.

> Have you seen "Metropolis?" If you just mean
> "fulfill some defined purpose", then you can see why I think that this is
> the same task as above, but on a smaller scale.

I haven't seen metropolis, but I get the general idea. I don't have
much sympathy for that kind of places.

> The product of this
> activity is also code. It's just more isolated code that isn't reflected
> throughout the system like the overall architectural components are. The
> processes used for creating all this code, and the purpose of all this code,
> is essentially the same. In all cases, the coder is defining the structure
> and operation of software.

I am not sure we disagree, but I think we have slightly different
experiences and because of that, different ways of working.

> I know you may not agree with my way of thinking about this, so to see who
> is more practically correct, perhaps we should see if we can find some sort
> of phase transition near the middle of the software development process that
> would justify your assignment of different labels to the pre-transition and
> post-transition phases:
>
> - Is there a point near the middle of development where schedules suddenly
> become firm? In my experience, no, there usually isn't. Certainty
> increases gradually and continually during development.

Sure. I still like to spend as much time as possible in the early
phases,
to try and get as much as "the big picture" as possible. Seeing the
likely post-project extensions is an advantage, it may pay off to
provide
certain hooks and labels early on, that would otherwise require an
extensive re-working.

> - Is there a point near the middle of development where feasibility suddenly
> becomes proven? I have found that doubts about feasibility can only be
> quelled by real implementations. It is a good idea to implement these
> questionable parts of a project early, but because these aren't usually
> isolated or architectural parts of the project, you can't just do them all
> first.

Agreed. However, in my book that's R&D-type projects that must be
treated
somewhat differently. At least, the "real" project should pe preceeded
by some sort of feasability study, or a termination clause should be
included in the contract if such questions are known beforehand.

> - Is there a point near the middle of development when you can validate all
> of your preceding assumptions with the customer? Again, in my experience,
> there is not. If customers could look at a project in progress and really
> determine whether or not it meets their needs, they wouldn't need you or me.

I have been involved in projects where that actually happened. True,
not
software projects, but data analysis pojects. The customer had an idea
about how to make a measurement, but they did not know how to actually
go through with it. From the customer's point of view, this was an R&D
project. As far as I was concerned, there was no R&D involved, only
using tried and tested techniques in a new setting. As we went through
the project, there were frequent dicussions about "can we replicate the

analysis results from the lab in a real-life setting? Can we get the
equipment to survive a real-life setting? Can we train production staff

to handle the equipment? Can we train analysts to include the data in
their analysis?" If the answer to any of these questions was "no",
the project was a "waste" of time and money, the equipment would not
reach its intended production stage.

But we didn't know the answers until we tried. The customer knew all
the constraints, I knew what the equipment needed to do. Sometimes
we could sacrifice some "convenient" gadget in the analysis, others
had to stay or the measuring device would not work. Sometimes we
we could change or adjust the existing operation process, other times
what we contemplated was a threat to the equpment we tried to make
more reliable and efficient. It was a really interesting project.

> So, if you still think that there is a real, practical, division of
> development into design and implementation phases, then when, oh when, does
> it occur, and what are the practical consequences of reaching it?

If you understand me such that I split "design" and "implementation"
into very separate phases, in time and perhaps even people, I have
expressed myself poorly. I am thinking of "design" in terms of
selecting
algorithms, organization the activity/program and, well, think the task

through before taking any actions. It's the antithesis to the "make
code now!" approach I have very poor experiences with.

There are usually several ways to get something done, one is usually
more favourable than others. This may depend on the actual
circumstances
of the project. "Design" is about analysing the problem and selecting
how to do things. It could be all those talks with the customer before
the project actually takes place, or it could be the coder deciding
whether to implement some function as a recursive call or some nested
loop.
Either one might get the job done right now, but "the big picture"
might
suggest that some task or extension becomes easier in the future,
should particular method be chosen over the other.

Rune

Rune Allnor wrote:

...


> through before taking any actions. It's the antithesis to the "make
> code now!" approach I have very poor experiences with.
>
> There are usually several ways to get something done, one is usually
> more favourable than others. This may depend on the actual
> circumstances
> of the project. "Design" is about analysing the problem and selecting
> how to do things. It could be all those talks with the customer before
> the project actually takes place, or it could be the coder deciding
> whether to implement some function as a recursive call or some nested
> loop.
> Either one might get the job done right now, but "the big picture"
> might
> suggest that some task or extension becomes easier in the future,
> should particular method be chosen over the other.

I've thrown out a lot of early code because it led to unfortunate data
structures or module interfaces. I'm not prescient enough to get those
right most of the time on unfamiliar ground, and I know it. My approach
is to write a quickie that covers most of the ground, try to use it, and
learn a better way from it. It would be a waste to give it more features
that what's needed for a shakedown, then I chuck it and start over. Many
programmers I admire work that way.*

Sometimes, I just do that in my head. I've actually debugged assembly
code by single-stepping it in my head as I drove home from work. I
suppose I should have been elated at finding my bug, but it made me feel
pretty stupid.

Throwing code away can be depressing if it was originally intended to be
kept, but making it part of the planning process takes the sting out.
Has there ever been a completed project that couldn't be improved by
another go-round? A quickie prototype can capture most of the benefit of
a second chance.

Jerry
_________________________________
* If the boss will insist that you flesh it out and keep it, do it in
secret. At home on your own time if need be.
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Fred Marshall wrote:
> "Jerry Avins" <[email protected]> wrote in message
> news:[email protected]..
>
>>Fred Marshall wrote:
>
> .....................
>
>>The bolts were already set into the concrete; what to do? The original
>>plan was bolting each end with a half-inch pad under it. We bolted one end
>>with its pad, and left a half-inch gap with no nut on the other end. That
>>end is supported by the bolt, but not longitudinally constrained by it.
>>Despite out harsher winters, there has been no cracking yet. But the
>>California installations weren't "broke", so despite all subsequent
>>installations using my floating hangers, the old ones weren't fixed. At
>>least one original southern California trough is now patched.
>>
>>Jerry
>>--
>
>
> Jerry,
>
> Well, you didn't have a working model in the context of your application.
> But you also didn't *prove* that cracking would occur did you? (If you did
> then OK - bear with me; I'm not suggesting that you didn't have a valid
> concern).

Most large structures have expansion joints or are carefully designed
not to need them. I considered the lack of them in the aerator supports
do be a design oversight and our consulting engineers agreed.

> What if it had been built for NJ and no failure occurred? And subsequently
> the worry came up?
> Should you change the implementation or not? Your example re: California is
> perfect! The worry was apparently sufficiently justified that taking the
> nuts off in California would have been the smart thing to do.

Not every design flaw jumps up and bites. Carelessness doesn't always
exact a price. (If it did, most of us would be sorely beaten.) Recall
that we used a turnkey design. Our engineers adapted it to the soil
conditions and supervised construction, but they didn't design it. The
California plants were the responsibility of other owners. The design
owner modified the plans that applied to new installations. Where we
slipped pipe over the bolts (kept in place by a nut on the bit of thread
that protruded) and enlarged the bolt holes, new installations used
smooth instead of threaded anchor rods. I do not know the weather
conditions before the California crack, but I was told that the damage
saw not from an earthquake.

> A lot depends on the change that's contemplated.
> I once had a job solving problems on a system that was in production. The
> idea was to solve the problem without introducing any additional parts. It
> was a great challenge and fun to solve the problems with that constraint.
> Very much like removing the nuts. Mind you, the solutions were changes -
> but ones that had been asked for.
>
> So, if all you had to do was remove some redundant nuts in order to make the
> design "better" then by all means. These notions are more guidelines than
> hard and fast rules.

Removing the nuts allows the steel to contract. One must remove the pad
between the steel and the concrete to allow the steel to expand. That's
difficult without disassembling the aerator.

...

> I'm pretty sure we agree on most of this....

Yes.
> At the core this is more about decision making. Your folks decided to not
> make changes in California.

See above. They weren't my folks. I don't know what the patent holder
recommended, nor the process use for deciding by the several California
owners.

> Were they driven to that decision because they
> didn't want to spend the money? Or, were they driven to that decision by
> blind allegiance to a "freeze" kind of rule?

"Freeze" is a bad word in the sewerage business. Requirements change as
effluent limits are changed by government and communities grow. Our
plant's sludge incineration system was designed when oil was cheap. The
presses that separate sludge from water were inefficient but rugged and
simple. The high water content of the "dried" sludge made continuous oil
or natural-gas firing necessary to get the poor bugs to burn. (Have you
ever held a handful of live bacteria? That's what sludge is.) Oil was
expensive by the time the plant when into operation. Within a few years,
we replaced the belt presses with more effective vacuum presses at no
small cost. (An energy-conservation grant helped.) The sludge now burns
on its own once the incinerators are up to temperature, but the presses
stank up the whole operations building. So we rebuilt the air handling
system, including scrubbers for the exhaust air so as not to gross out
the neighbors. Then we ... It never ends. Although I'm no longer a
commissioner, I'm still officially involved, mostly with odor control.
The plant seems to be as much alive as the bacteria that make it work.

> I'll bet it's the former and,
> on a comparative basis, I agree with that being the driver even if we might
> disagree in hindsight (or in foresight) with the decision they made.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

The Design can (and shoule) also tell you things that the code doesn't -
like the relationship between functions, the flow of data, etc.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------


"Jerry Avins" <[email protected]> wrote in message
news:[email protected]..
> Matt Timmermans wrote:
> >
> >
> > In my shop, unless I have to pass an audit, the products of all these
> > activities are mostly code. At the level you're describing, most of
this
> > code is just interfaces, comments, and glue, but it is real code that
> > becomes part of the project. After all, it is code that really defines
the
> > algorithms that get used, and the program organization, etc. The code
will
> > be documented with block diagrams, overviews, various bits of UML, etc.,
in
> > order to communicate its gestalt more clearly, but most of the work here
is
> > code.
>
> The design part consists of deciding what the used will see and what he
> must to. Coding comes after. Design can be a chapter at a time, or the
> whole manual, but at every point along the way, you need a direction.
>

"Jerry Avins" <[email protected]> wrote in message
news:[email protected]..
> Fred Marshall wrote:
>> "Jerry Avins" <[email protected]> wrote in message
>> news:[email protected]..
>>
>
> "Freeze" is a bad word in the sewerage business. Requirements change as
> effluent limits are changed by government and communities grow. > Jerry
> --

Well, it would be in a lot of businesses. The context of freezing, in my
mind, is short time frame vs. medium or longer time frame. You adopt the
concept of freezing in order to keep things moving in the short term. You
adapt as you must. If you must adapt in the short term then so be it.
However, that is "requirements pull" vs. "technology push". Requirements
pull probably always trumps technology push.

I well understand your comment:
We built a new wastewater plant (2 batch reactors) for our City. It was a
100% replacement. It was designed to have adequate capacity margin. It was
deemed "topped out" by the Dept. of Ecology (DOE) when it came on line -
with virtually no new hookups. Why? Because the engineers designed it
under the assumption that inflow and infiltration (I&I) would be drastically
reduced as part of a parallel project. The City is over 100 years old and
some of the pipes are quite old and there is undoubtedly stormwater
intentionally (but undocumented / unknown) piped into the sanitary sewer
from long ago. Nobody in their right mind would predict a large % decrease
in I&I by virtue of a single fixit project in a City of this type. But they
did.

So, we built a 3rd reactor recently. As we improve I&I, the DOE allows more
capacity but the rate of improvement is slow so we had to do this.

Did the requirements change? No; not during construction because the
"requirements" were those assumed by the engineers. And yes; for the better
but not as fast as expected and planned for. And no; because the engineers
requirements didn't line up with the performance used by the DOH. So, the
requirements were faulty and a change in a moderate time frame was
necessary.
Actually, other changes were done on the first two batch reactors to make
them more productive - but, again, it was post-construction because that's
when the idea struck. Actually, I think the latter change was a matter of
requirements pull and realization that there was better technology
available.

You freeze in order to keep out the inadvisable changes that would come if a
variety of personalities had free rein. So rather than diminishing the
value of the idea outright, it's best to consider that there might be good
purpose and application of the idea.

Here's a context for it:
You have a bunch of folks designing something and some of them are really
bright but aren't very "common sense". They keep changing things. The
project stretches because of the spinoff affects of the changes. Little is
gained by the stretch - in fact, it costs money. So, you create some
hurdles for the changes to cross; you set some (perhaps arbitrary) time
points where there will be a "freeze" - which is a hurdle.
First changes are easy to make.
Then they are made a little harder to make.
Then they are made pretty hard to make.
Much can have to do with how "integrated" the thing is that's being changed
or how far into production it is or how many already exist in the field that
have to be maintained, etc. etc.

Fred

Fred Marshall wrote:
> "Jerry Avins" <[email protected]> wrote in message
> news:[email protected]..
>
>>Fred Marshall wrote:
>>
>>>"Jerry Avins" <[email protected]> wrote in message
>>>news:[email protected]..
>>>
>>
>>"Freeze" is a bad word in the sewerage business. Requirements change as
>>effluent limits are changed by government and communities grow. > Jerry
>>--
>
>
> Well, it would be in a lot of businesses. The context of freezing, in my
> mind, is short time frame vs. medium or longer time frame. You adopt the
> concept of freezing in order to keep things moving in the short term. You
> adapt as you must. If you must adapt in the short term then so be it.
> However, that is "requirements pull" vs. "technology push". Requirements
> pull probably always trumps technology push.
>
> I well understand your comment:
> We built a new wastewater plant (2 batch reactors) for our City. It was a
> 100% replacement. It was designed to have adequate capacity margin. It was
> deemed "topped out" by the Dept. of Ecology (DOE) when it came on line -
> with virtually no new hookups. Why? Because the engineers designed it
> under the assumption that inflow and infiltration (I&I) would be drastically
> reduced as part of a parallel project. The City is over 100 years old and
> some of the pipes are quite old and there is undoubtedly stormwater
> intentionally (but undocumented / unknown) piped into the sanitary sewer
> from long ago. Nobody in their right mind would predict a large % decrease
> in I&I by virtue of a single fixit project in a City of this type. But they
> did.
>
> So, we built a 3rd reactor recently. As we improve I&I, the DOE allows more
> capacity but the rate of improvement is slow so we had to do this.
>
> Did the requirements change? No; not during construction because the
> "requirements" were those assumed by the engineers. And yes; for the better
> but not as fast as expected and planned for. And no; because the engineers
> requirements didn't line up with the performance used by the DOH. So, the
> requirements were faulty and a change in a moderate time frame was
> necessary.
> Actually, other changes were done on the first two batch reactors to make
> them more productive - but, again, it was post-construction because that's
> when the idea struck. Actually, I think the latter change was a matter of
> requirements pull and realization that there was better technology
> available.
>
> You freeze in order to keep out the inadvisable changes that would come if a
> variety of personalities had free rein. So rather than diminishing the
> value of the idea outright, it's best to consider that there might be good
> purpose and application of the idea.
>
> Here's a context for it:
> You have a bunch of folks designing something and some of them are really
> bright but aren't very "common sense". They keep changing things. The
> project stretches because of the spinoff affects of the changes. Little is
> gained by the stretch - in fact, it costs money. So, you create some
> hurdles for the changes to cross; you set some (perhaps arbitrary) time
> points where there will be a "freeze" - which is a hurdle.
> First changes are easy to make.
> Then they are made a little harder to make.
> Then they are made pretty hard to make.
> Much can have to do with how "integrated" the thing is that's being changed
> or how far into production it is or how many already exist in the field that
> have to be maintained, etc. etc.

I&I is always a problem. The sanitary lines under approximately 1500
slab-floor houses, including mine, were surreptitiously cracked just
before the slabs were poured to provide drainage to avoid their getting
damp from ground water. When it rains, it pours in. Since each community
pays for its portion of operating expenses _and_sunk_capital_expenses_
in proportion of its flow, there is strong incentive for each
participant to reduce its flow to the minimum. Expenditures for I&I
reduction are sound investment. We could swap stories all week, but I
think it's getting pretty remote for now.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

"Jerry Avins" <[email protected]> wrote in message
news:[email protected]..
> Before I write code, I want to know what it's supposed to do.

Sure, but you have to know that before you write design docs, too.

> When it's for a client, I want to be very sure that the client knows it's
> supposed to do.

They know about it in their own head-space. If you ask an engineer to build
you a bridge, for example, you probably know where you want it to go and
what kind of traffic you want to drive across it, but that's not all a
bridge does. It's up to the engineer to anticipate additional loads from
wind, temperature changes, tides and currents, etc. What the bridge does is
deal with all of these things, but it's not fair to ask a customer to
describe the parameters to which he expects his bridge to conform, because
he doesn't even know what's reasonable.

> I did programming for hire for a time, sometimes moonlighting, and for a
> while as part of my only professional activity. I learned from other's bad
> experiences before I started to insist on a set of specifications that
> would allow the client to prove that I didn't finish the job, and allow me
> to prove that I did.
> Some clients didn't like to be pinned down [...]

There's some level of CYA you have to do when you're working on a contract
basis, but even here I think that the onus is primarily on the software
engineering professional to be personally sure that he is delivering what
the customer needs. There is a lot of customer interaction required to
create that surety, of course -- more than is required just to safely paint
the customer into a workable corner.

> The design part consists of deciding what the used will see and what he
> must to. Coding comes after.

Yes, there's a lot of that that needs to happen before coding, of course.

--
Matt