Hello, I'm interested in how individuals or design groups manage
complexity in their design projects. What things do you do or things
the group does that can take complex tasks and break them into simpler
or more manageable tasks? It may sound like a weird question, but there
must be some guidelines, best practices, or habits used to achieve
success in designing/developing a complex project. I'm sure there must
be some individuals out there that are constantly taking complex tasks
and just about every time have success with it. Short of speaking, I
want to know what's the secret to their success. All comments are
welcomed, even the most obvious suggestions.

As an engineer, I'm constantly trying to improve my design processes.

Thanks everyone,
joe

<jjlindula@hotmail.com> wrote in message
news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.

If there was a fairly simple answer to this question - a lot of talented
people would become not-so-talented very quickly.
What makes large complex design projects a challenge other than the
engineering complexity is the fairly strong influence of several external
factors....like, engineering resources available, their talents, budget,
time, skill of project manager(s), etc.
This makes for such a complex set of inter-related things that it's really
really hard to talk about one while ignoring the others.

The secret to the success of these individuals you speak of (I'm yet to meet
one) is a good understanding of all the factors (and probably a few more
that I can't think of). Quite a bit of this comes from experience...so I'd
imagine this person to have participated and/or managed several complex
projects before being able to consistently succeed.

In short, I think some level of success can be achieved by removing whatever
it is that makes a task 'complex'. So whatever one can do to break down the
tasks so that they aren't 'complex' anymore should be an excellent start. By
doing this, you expose the complexity of the task to yourself (and maybe a
few select others) and all others involved get to deal with a fairly
straightforward and simple task - thereby reducing risk which I think is
fairly key to this.

Cheers
Bhaskar
P.S - I can easily see a counter argument where someone might say that risk
should be divided equally among several people rather than 1 person taking
on all the risk (thereby reducing risk :-)) - I don't know which option is
better - I'd say "it depends" :-)


> As an engineer, I'm constantly trying to improve my design processes.
>
> Thanks everyone,
> joe
>

Hierarchical design.  Every complex design or algorithm is an aggregate 
of simpler subsystems. By using hierarchy, you get a fairly simple 
representation at every level in the design, and with the exception of 
the leaf nodes, the design is an exercise of defining and then stitching 
together the sub-blocks.  The designs at the leaf nodes are simple 
designs (if they aren't then they should also be broken into sub-modules).

With a proper definition of each block, the blocks can be broken out 
into independent designs with the responsibility of meeting the 
interface specifications falling on whoever designs that block.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

jjlindula wrote:

> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects.

Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the
best case possible for incremental design. You build a prototype, see if it
works, tweak it a little, and repeat over many iterations.

> What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks?

Sort feature requests by business priority and implement the most important
ones first.

> It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.

Write unit tests for each tiny feature, as you write the feature.

-- 
  Phlip
  http://www.c2.com/cgi/wiki?ZeekLand

jjlindula@hotmail.com wrote:

 > Hello, I'm interested in how individuals or design groups manage
 > complexity in their design projects.

Good question.
This is a little like teaching a correspondence course
on backing a trailer down a winding driveway and parking
it in a tight spot. The student can only really learn the thing
by trial and error, but here's my list anyway.

*Tools*
1. _Source/version control_
Without this, development often moves
backward instead of forward.

2. _Text Editor_ that knows the language and
can quickly browse the design, run make and
and fire off test cases or simulations.
This edit/compile/test loop will be run thousands of
times during a project.

*Process*
1. Acquire tools, requirements and sample data.
This is the hardest part.

2. Prove the point on the sample data first,
then fill in the stubbed out functions and procedures.
Find the top of the tree before working out
the shape and color of the leaves.

3. Code using the design rules taught by previous sore experience.

4. Use hierarchy only as needed in your own code. There will
be plenty of hierarchy required just to hook together modules by others 
and for reused/purchased modules. Overuse of  hierarchy
makes design intent difficult to understand from the code level.

* Regression *
Once a module works in the system, collect the best
test cases and construct a pass/fail regression
test or test bench. Rerun this test before
committing any edits to the module.

*Update Design Rules*
Before the project is out of short term memory,
update the design rules to cover any new lessons learned.

   -- Mike Treseler

jjlindula@hotmail.com wrote:
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.


Howdy Joe,

In addition to the excellent suggestions that others have already
posted about design steps, tools, resouces, etc, I believe it is pretty
important to:

1. Have VERY well defined requirements
2. Have a good understanding of the requirements
3. Have requirements that don't change a lot over the course of the
project
4. Have at least a few engineers with enough foresight to anticipate
likely changes to the requirements so that minor alterations don't
result in a complete redesign
5. Start with known good designs (or parts of them) whenever possible
6. Have engineers you trust to get the job done and let them do the
work


A few notes on some of these:

On #6: Don't waste the engineers' precious hours each day by constantly
looking over their shoulder (or dragging them into hour long status
meetings every day).

Other posters have mentioned aspects of #5, but I'd like to expand on
it: starting with a known good design (or hierarchical block) not only
saves time and effort during the initial design, but pays off even more
when debug time comes around.  If parts of a design are known to be
good, debugging efforts can first focus on the newer stuff that isn't
as trusted.  It also provides a base of commonality for higher level
stuff (like software).

With regards to #4, I'm not saying that all the engineers on a project
need to be experienced.  But probably 1 in 5 (or so) should be, in my
opinion.  #4 can also can directly feed into #5.  A well designed unit
can be reused for many other applications, saving absolutely HUGE
amounts of time in the future(*).  Said another way, blocks should be
as generic as possible so they will be more likely to be easily reused.

BTW, you haven't defined what a succesful project is.  If part of the
definition is on-time delivery, there may be fewer "successful" complex
projects than you think :-)

Have fun,

   Marc

(*) Very simple example: As long as it does NOT use more resources,
rather than creating three different cores for 512x6, 128x8, and 256x9
memories, create one that is 512x9 and use it in all three instances,
tieing off unused inputs.

<jjlindula@hotmail.com> wrote in message 
news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.
>

Joe,

Here is another perspective:

People are the source of complexity.

Better" is the enemy of "good enough".

One reason the requirements need to be understood is to avoid changes.

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.

It doesn't happen often that it isn't, but try to make sure that the thing 
is feasible in our lifetime - otherwise it isn't engineering it's an 
experiment.

Sometimes you won't know the requirements until you've tried some things.

More wires mean more complexity.

If you don't understand what you're doing, and understand it very well, then 
you'll make a lot of dumb mistakes.  It's easy enough to make dumb mistakes 
when you *do* understand it very well!

One person has to be able to wrap their head around the whole thing - but 
not necessarily all the parts as long as the parts are well known things and 
under somebody's cognizance and control.  This is where you need to be 
careful about the thing (maybe one of the parts and maybe the whole) being 
feasible in our lifetime.  One of the parts may be akin to "and then a 
miracle occurs".

If it's deemed "complex" to begin with then the core staff should be fairly 
well full time.  People need to wake up in the middle of the night wondering 
if they've taken care of this and that - and they need to have undivided 
attention to the challenges so they will solve a knotty problem while 
sailing on the bay.  If they get assigned to other things, you lose this 
subconscious attention - which has really high value.

I don't know how to best express how to apply ideas of hierarchy, 
partitioning and so forth.  But, that seems where the best payoff is in 
reducing complexity.  Maybe we might ask how that really keen understanding 
is achieved?  It's through analysis, partitioning, trying out ideas, etc. 
until something that really makes sense results.  I do it but I can't quite 
describe how.

Fred

jjlindula@hotmail.com wrote:
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
> 
> As an engineer, I'm constantly trying to improve my design processes.
> 
> Thanks everyone,
> joe

Joe,

One of the people I respect most in this area is Paul Bennett, 
http://www.amleth.demon.co.uk/hidecs/. He is a regular at 
comp.lang.forth and sci.engr.control.

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

On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:

>jjlindula wrote:
>
>> Hello, I'm interested in how individuals or design groups manage
>> complexity in their design projects.
>
>Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the
>best case possible for incremental design. You build a prototype, see if it
>works, tweak it a little, and repeat over many iterations.
>

As opposed to, say, thinking it through carefully and getting it right
the first time?

John

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
news:sdu0e1h5or9d6dbe6akavdov7bnqh6c9ld@4ax.com: 

> On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
> 
>>jjlindula wrote:
>>
>>> Hello, I'm interested in how individuals or design groups manage
>>> complexity in their design projects.
>>
>>Read /Notes on the Synthesis of Form/ by Christopher Alexander. It
>>makes the best case possible for incremental design. You build a
>>prototype, see if it works, tweak it a little, and repeat over many
>>iterations. 
>>
> 
> As opposed to, say, thinking it through carefully and getting it right
> the first time?
> 
> John
> 

Complexity causes projects to increase in time exponentially. Without a 
good assessment of the scope of the project, I think the approach taken can 
vary considerably. 

You need at least one project architect to guide the project. I am not a 
big proponent on extremely detailed project specifications. I think this 
all to often leads to a finished product that nobody wants. I think you 
need to leave some room for improved ideas and innovations that typically 
occur as you develop the product. Of course, this needs to be balanced with 
getting the project done. There is a time when you have to "shoot the 
engineer and start production" 

I also rarely take the build a little, tweak a little approach. Time to 
market will usually kill you. This doesn't mean that you ignore little 
problems or bugs in your design. These are going to come back and bite you.

On the larger projects that I have worked on, We start with a good plan and 
a vision of what we want the outcome of our product to be with trying to 
define every last detail. We might prototype the small sections that we 
know the least about. Most of the time there are large portions of a 
project that are already fairly well understood by our team. I like to 
design the early pieces close to the finished result. In some cases, an 
iteration or two is all you need to have a finished product. In other 
cases, you throw away most of the design and start over, with a much better 
understanding of where you need to go. I think this approach used to be 
called fast prototyping. 


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

A number of people have talked about hierarchy. I have inherited a
number of designs, both PCB and firmware, where hierarchy was used
because the piece of paper wasn't big enough.

I would suggest that you should be able to look at any hierarchical
block and be able to explain what it does in a couple of sentences,
then you enter the block to find out how it does it.

Colin

jjlindula@hotmail.com wrote:
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.
> 
> Thanks everyone,
> joe

John Larkin wrote:

>On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
>
>  
>
>>jjlindula wrote:
>>
>>    
>>
>>>Hello, I'm interested in how individuals or design groups manage
>>>complexity in their design projects.
>>>      
>>>
>>Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the
>>best case possible for incremental design. You build a prototype, see if it
>>works, tweak it a little, and repeat over many iterations.
>>
>>    
>>
>
>As opposed to, say, thinking it through carefully and getting it right
>the first time?
>
>John
>  
>
If you can think something through carefully and get it right first 
time, without experimentation, you are either:

a) a genius who would make Newton look like a moron, or

b) doing something pretty trivial.

Regards,
Steve

The design rule is Minimizing The Complexity. Do not rely on the false
and unfortunately quite popular idea that any simple HW/SW design is
'stupid'. It's better to make $$$ with 'stupid' product than stuck with
complex but 'clever' one ...

Kind russian regards,
Yuri

jjlindula@hotmail.com wrote:
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.

I don't have much experience in project managment (exept for some
of my own more or less "hobby" projects), but I have been around
a couple of bad projects, and there are one or two things I would
like to see tested out in practice.

First, there must be *one* person in charge, and this must be the
person who really *is* in charge.

To take the last first, I have seen projects here one person is
nominally in charge (e.g. the young, ambitious "fast-track'er")
while another person is de facto in charge (e.g. the "old fox"
in the engineering staff.) That's basically a recipe for disaster.

You have to have *one* project boss (who might be held responsible
by a board of directors, but they are outside the project as such)
that has all the responsibility within the project. Divided
responsibilities just don't work at the project managment level.

Second, the person in charge must be competent. The whole problem
scope must fit in the mind of one person. The application, the
technology, the implementation. All such aspects bring their own
issues into the project, and must be considered. There may be (and
probably are) people in the project who have deeper/more specialized
knowledge than the boss of each single aspect, but the project boss
must have working knowledge of all relevant aspects.

A "trival" corollary from the above, is that project managers
are recruited amongst the more experienced engineering staff,
not amongst lawyers, economists or "fast-trackers" (even engineering
"fast-trackers").

Third, you need to get trained engineers in the staff, and you
need to supervise them "properly" during the project. Put younger
people work along side the elderly, novices with experts. The
inexperienced get to know what's expected from them, and have a
chance of seeing what it takes to deliver. The experts get some
help in doing the more mundane tasks, some even find it fun/rewarding
to train novices and youngsters.

Fourth, keep the teams small and keep them responsible for their
deliveries. Make sure to give them credit where credit is due.
If something goes wrong, have a look at the brief the team had
to work from, whether the goals were feasible within the allocated
time and resources etc, before blaming single members of the teams
for any sort of failure.

Fifth, as boss you are most likely to face people in the team
who have more specialized skills (and perhaps even more overall
skills) than yourself. Be aware of that, and show that you are
aware. The kind of people you work with can be *really* smart
in their respective fields. Such people tend not to take lightly
on people who try to display a competence they in reality don't
have. It is way better to ask "would you help me understand how
to do this" instead of taking on some sort of "bravado" mask
of "this was obvious" when presented with a clever piece of
engineering. The humble approach might gain the boss some respect,
it certainly provides the generalist with an oportunity to learn
from the specialists.

Sixth, set a three-level goal for the project:

A) The "bare survival" delivery, that *just* meets the project
   goals, without you being sued/fired/go bancrupt/flunk the exam...
B) The "decent" delivery, that meets the goals with a comfortable
   margin, where there are used "decent" techniques and solutions
   as opposed to "quick'n dirty" ones, all documentation is ready etc.
C) The "ideal" solution, where absolutely everything went your way,
   and where you used all the nifty algorithms, included all the
   fun bells'n whistles etc, the whole software program is fully
   portable, easily extendable, on-the-fly reconfigurable,
   everything is documented and available in six languages...

Being aware of level A) is an absolute must. Being aware of the
difference between levels A) and B) comes in handy.  Level C) is,
as of yet, just an illusive dream in my world, and was included
more for completeness than anything else...

Seventh, don't demand from others what you are not willing to, or
capable to, yield yourself. It's basically about the manager/boss
setting an example of what is expected from the project team.
If there are demands to, say, documentation of the product, the
development process, or anything  else, provide the tools for the
programmers to make that documentation. If the project documents
are required to have a certain layout, the boss provides the
(working!) macros or packages that make the text processor produce
the layout.

You would be surprised how much "bad blood" is generated by putting
hard (allbeit reasonable) demands to the crew *without* providing
the means to meet them. Basically, once the project team respects
the project boss, on a personal and professional level and see that
he knows what he is doing, there will be a lot less strain once the
going gets though. As it always does.

As far as I am concerned, it's all about getting the right people
in the right places, and once there, getting them to work efficently.
I know it isn't always possible, but paying some attention to who
goes in what position, what tools are available to them etc, makes
quite a difference. If the team can't find a way to work together,
the project is lost. If the team members don't trust or respect the
boss, the project is lost. If the boss doesn't know his way around
either one of the application, the technology, the tools or the
implementation, the project is lost.

> As an engineer, I'm constantly trying to improve my design processes.

That's a goal I sincerely sympathize with. There is always something
to learn, something to improve on.

Rune

this mentality has been adopted in our company, the natural result of
this is ultra conservative designs because everyone is afraid that they
will be the one to screw up the schedule.

there is something to be said for prototypes, I can't imagine your
going to build anything innovative by just thinking it all out on paper
and/or computer simulation, data sheets are typically not comprehensive
or contain errors, circuit simulations are not accurate (especially
noise estimates, almost impossible to predict accurately) ,  engineers
are not perfect, they sometimes misread a datasheet or just make a
error, a prototype can quickly confirm the robustness of a design

John Larkin wrote:

> As opposed to, say, thinking it through carefully and getting it right
> the first time?

The secret message of the book is that's what "heroic" architects like Frank
Lloyd Wright do.

Google his name and "leaky".

-- 
  Phlip
  http://www.c2.com/cgi/wiki?ZeekLand

Joe wrote:

>All comments are
>welcomed, even the most obvious suggestions.

"The Mythical Man-Month: Essays on Software Engineering" by Frederick
P. Brooks.

The hardware types should not focus on "Software" in the title, the
book is about the nature of individuals and groups working on complex
projects.


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email

<ytregubov@yahoo.com> wrote in message
news:1122021099.971139.117790@f14g2000cwb.googlegroups.com...
> The design rule is Minimizing The Complexity. Do not rely on the false
> and unfortunately quite popular idea that any simple HW/SW design is
> 'stupid'. It's better to make $$$ with 'stupid' product than stuck with
 complex but 'clever' one ...

I agree with the assessment, but keep in mind that it's a lot easier for
others to compete against someone making simple designs than those making
complex designs.  On the other hand, my experience is that many projects fail
much more due to poor planning, customer service (not meeting the customer's
needs, even if the customer isn't fully aware of their own needs!), etc. than
any real technical hurdles.

I also would say that, while nothing should be more complex than it needs to
be (a variant of Einstein's quote), many products today are expected to
'evolve' over time.  That is, the same basic hardware/software platform gets
reused in more than one project.  In such cases, increases in complexity are
warranted if they make the '2nd generation' product that much easier to
produce.  Many engineers and programmers try to make the excuse that they
don't have time to make a flexible, structured, 'polished' design and end up
building something that -- while the first article out the door might happen
sooner -- the product has higher failure rates during production or in the
field and the 2nd generation timeline ends up being completely shot.

Most critical of all, though, is finding the right people.  Really good
engineers and programmers vs. the average ones can easily make a 2:1
difference in productivity, and given the option I'd rather have all those
folks around and pay them twice as much as the average folks.

---Joel Kolstad

Rune Allnor wrote:

> 
> jjlindula@hotmail.com wrote:
> 
>>Hello, I'm interested in how individuals or design groups manage
>>complexity in their design projects. What things do you do or things
>>the group does that can take complex tasks and break them into simpler
>>or more manageable tasks? It may sound like a weird question, but there
>>must be some guidelines, best practices, or habits used to achieve
>>success in designing/developing a complex project. I'm sure there must
>>be some individuals out there that are constantly taking complex tasks
>>and just about every time have success with it. Short of speaking, I
>>want to know what's the secret to their success. All comments are
>>welcomed, even the most obvious suggestions.
> 
> 
> I don't have much experience in project managment (exept for some
> of my own more or less "hobby" projects), but I have been around
> a couple of bad projects, and there are one or two things I would
> like to see tested out in practice.
> 
> First, there must be *one* person in charge, and this must be the
> person who really *is* in charge.
> 
> To take the last first, I have seen projects here one person is
> nominally in charge (e.g. the young, ambitious "fast-track'er")
> while another person is de facto in charge (e.g. the "old fox"
> in the engineering staff.) That's basically a recipe for disaster.
> 
> You have to have *one* project boss (who might be held responsible
> by a board of directors, but they are outside the project as such)
> that has all the responsibility within the project. Divided
> responsibilities just don't work at the project managment level.
> 
Delagated responsibilities, however, are a must.

> Second, the person in charge must be competent. The whole problem
> scope must fit in the mind of one person. The application, the
> technology, the implementation. All such aspects bring their own
> issues into the project, and must be considered. There may be (and
> probably are) people in the project who have deeper/more specialized
> knowledge than the boss of each single aspect, but the project boss
> must have working knowledge of all relevant aspects.
> 
If you mean that the project manager must be able to work on any piece 
of the thing that isn't so.  On a really complex project no one person 
can embrace the whole thing in detail.  The project manager should be 
able to grasp the interactions of the pieces, however.

> 

snip

> Sixth, set a three-level goal for the project:
> 
> A) The "bare survival" delivery, that *just* meets the project
>    goals, without you being sued/fired/go bancrupt/flunk the exam...
> B) The "decent" delivery, that meets the goals with a comfortable
>    margin, where there are used "decent" techniques and solutions
>    as opposed to "quick'n dirty" ones, all documentation is ready etc.
> C) The "ideal" solution, where absolutely everything went your way,
>    and where you used all the nifty algorithms, included all the
>    fun bells'n whistles etc, the whole software program is fully
>    portable, easily extendable, on-the-fly reconfigurable,
>    everything is documented and available in six languages...
> 
> Being aware of level A) is an absolute must. Being aware of the
> difference between levels A) and B) comes in handy.  Level C) is,
> as of yet, just an illusive dream in my world, and was included
> more for completeness than anything else...
> 
This sort of excersize is very good for focussing the mind, and also 
works for each of the pieces.  It's always a good idea to put as many 
hooks into the design to let you achieve 'C' later, even if you can only 
achieve 'A' now.

> Seventh, don't demand from others what you are not willing to, or
> capable to, yield yourself. It's basically about the manager/boss
> setting an example of what is expected from the project team.
> If there are demands to, say, documentation of the product, the
> development process, or anything  else, provide the tools for the
> programmers to make that documentation. If the project documents
> are required to have a certain layout, the boss provides the
> (working!) macros or packages that make the text processor produce
> the layout.
> 
Here again I'm going to disagree.  I've been on well run projects where 
this sort of task (not this exact one) has been delagated by the project 
manager to someone better able to do it.  Note, however, that the 
project manager still takes responsibility for what he delagates. 
Frankly, if the project manager can delagate effectively and keep the 
team happy he doesn't have to know squat -- except that not knowing 
squat is a barrier to effective delagation...

> You would be surprised how much "bad blood" is generated by putting
> hard (allbeit reasonable) demands to the crew *without* providing
> the means to meet them. 

Yea verily.

> Basically, once the project team respects
> the project boss, on a personal and professional level and see that
> he knows what he is doing, there will be a lot less strain once the
> going gets though. As it always does.
> 
> As far as I am concerned, it's all about getting the right people
> in the right places, and once there, getting them to work efficently.
> I know it isn't always possible, but paying some attention to who
> goes in what position, what tools are available to them etc, makes
> quite a difference. If the team can't find a way to work together,
> the project is lost. If the team members don't trust or respect the
> boss, the project is lost. If the boss doesn't know his way around
> either one of the application, the technology, the tools or the
> implementation, the project is lost.
> 
> 
>>As an engineer, I'm constantly trying to improve my design processes.
> 
> 
> That's a goal I sincerely sympathize with. There is always something
> to learn, something to improve on.
> 
> Rune
> 


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Ray Andraka wrote:

> Hierarchical design.  Every complex design or algorithm is an aggregate 
> of simpler subsystems. By using hierarchy, you get a fairly simple 
> representation at every level in the design, and with the exception of 
> the leaf nodes, the design is an exercise of defining and then stitching 
> together the sub-blocks.  The designs at the leaf nodes are simple 
> designs (if they aren't then they should also be broken into sub-modules).
> 
> With a proper definition of each block, the blocks can be broken out 
> into independent designs with the responsibility of meeting the 
> interface specifications falling on whoever designs that block.
> 
This should be done, however, by an individual (or _very_ small team) 
who understands what can reasonably be asked of each node -- otherwise 
you end up with an imbalanced or just plain impossible design.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

<jjlindula@hotmail.com> wrote in message 
news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.
>
> Thanks everyone,
> joe
>

What I've found, (in short) is that a project manager has to active in the 
art form of communications. He has to be a "people person".  Start treating 
someone like one of those little MS Project bars and you'll soon see those 
bars grow. It very easy for a engineer to pass the buck when so many people 
are involved. It's a lot better if he cares about the projects completion 
and respects the project manager.

Oh ya, and the term "commands respect" doesn't work with the smart 
engineers.

Thomas 

Tim Wescott wrote:
> Rune Allnor wrote:
>
> >
> > jjlindula@hotmail.com wrote:
> >
> >>Hello, I'm interested in how individuals or design groups manage
> >>complexity in their design projects. What things do you do or things
> >>the group does that can take complex tasks and break them into simpler
> >>or more manageable tasks? It may sound like a weird question, but there
> >>must be some guidelines, best practices, or habits used to achieve
> >>success in designing/developing a complex project. I'm sure there must
> >>be some individuals out there that are constantly taking complex tasks
> >>and just about every time have success with it. Short of speaking, I
> >>want to know what's the secret to their success. All comments are
> >>welcomed, even the most obvious suggestions.
> >
> >
> > I don't have much experience in project managment (exept for some
> > of my own more or less "hobby" projects), but I have been around
> > a couple of bad projects, and there are one or two things I would
> > like to see tested out in practice.
> >
> > First, there must be *one* person in charge, and this must be the
> > person who really *is* in charge.
> >
> > To take the last first, I have seen projects here one person is
> > nominally in charge (e.g. the young, ambitious "fast-track'er")
> > while another person is de facto in charge (e.g. the "old fox"
> > in the engineering staff.) That's basically a recipe for disaster.
> >
> > You have to have *one* project boss (who might be held responsible
> > by a board of directors, but they are outside the project as such)
> > that has all the responsibility within the project. Divided
> > responsibilities just don't work at the project managment level.
> >
> Delagated responsibilities, however, are a must.

Agreed. "Divided" and "delegated" are two very different concepts.

> > Second, the person in charge must be competent. The whole problem
> > scope must fit in the mind of one person. The application, the
> > technology, the implementation. All such aspects bring their own
> > issues into the project, and must be considered. There may be (and
> > probably are) people in the project who have deeper/more specialized
> > knowledge than the boss of each single aspect, but the project boss
> > must have working knowledge of all relevant aspects.
> >
> If you mean that the project manager must be able to work on any piece
> of the thing that isn't so.  On a really complex project no one person
> can embrace the whole thing in detail.  The project manager should be
> able to grasp the interactions of the pieces, however.

Yep. That ability comes with experience, and from working over a
long time with specialists from other diciplines. As for myself,
I don't know how to run a ship. But having been to sea, I have an
impression of what can and what can not be done. And I try to
take those experiences into account when I discuss sea trials and
marine operations.

> >
>
> snip
>
> > Sixth, set a three-level goal for the project:
> >
> > A) The "bare survival" delivery, that *just* meets the project
> >    goals, without you being sued/fired/go bancrupt/flunk the exam...
> > B) The "decent" delivery, that meets the goals with a comfortable
> >    margin, where there are used "decent" techniques and solutions
> >    as opposed to "quick'n dirty" ones, all documentation is ready etc.
> > C) The "ideal" solution, where absolutely everything went your way,
> >    and where you used all the nifty algorithms, included all the
> >    fun bells'n whistles etc, the whole software program is fully
> >    portable, easily extendable, on-the-fly reconfigurable,
> >    everything is documented and available in six languages...
> >
> > Being aware of level A) is an absolute must. Being aware of the
> > difference between levels A) and B) comes in handy.  Level C) is,
> > as of yet, just an illusive dream in my world, and was included
> > more for completeness than anything else...
> >
> This sort of excersize is very good for focussing the mind, and also
> works for each of the pieces.  It's always a good idea to put as many
> hooks into the design to let you achieve 'C' later, even if you can only
> achieve 'A' now.

My thoughts exactly.

> > Seventh, don't demand from others what you are not willing to, or
> > capable to, yield yourself. It's basically about the manager/boss
> > setting an example of what is expected from the project team.
> > If there are demands to, say, documentation of the product, the
> > development process, or anything  else, provide the tools for the
> > programmers to make that documentation. If the project documents
> > are required to have a certain layout, the boss provides the
> > (working!) macros or packages that make the text processor produce
> > the layout.
> >
> Here again I'm going to disagree.  I've been on well run projects where
> this sort of task (not this exact one) has been delagated by the project
> manager to someone better able to do it.  Note, however, that the
> project manager still takes responsibility for what he delagates.

While my post may be phrased that way, I don't mean litterally
that the manager should do it himself. "See to that it is done"
suffices. But that's a must.

> Frankly, if the project manager can delagate effectively and keep the
> team happy he doesn't have to know squat -- except that not knowing
> squat is a barrier to effective delagation...

My point exactly.

> > You would be surprised how much "bad blood" is generated by putting
> > hard (allbeit reasonable) demands to the crew *without* providing
> > the means to meet them.
>
> Yea verily.
>
> > Basically, once the project team respects
> > the project boss, on a personal and professional level and see that
> > he knows what he is doing, there will be a lot less strain once the
> > going gets though. As it always does.
> >
> > As far as I am concerned, it's all about getting the right people
> > in the right places, and once there, getting them to work efficently.
> > I know it isn't always possible, but paying some attention to who
> > goes in what position, what tools are available to them etc, makes
> > quite a difference. If the team can't find a way to work together,
> > the project is lost. If the team members don't trust or respect the
> > boss, the project is lost. If the boss doesn't know his way around
> > either one of the application, the technology, the tools or the
> > implementation, the project is lost.
> >
> >
> >>As an engineer, I'm constantly trying to improve my design processes.
> >
> >
> > That's a goal I sincerely sympathize with. There is always something
> > to learn, something to improve on.
> >
> > Rune
> >
>
>
> --
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

Rune

John Larkin wrote:
> On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
> 
> 
>>jjlindula wrote:
>>
>>
>>>Hello, I'm interested in how individuals or design groups manage
>>>complexity in their design projects.
>>
>>Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the
>>best case possible for incremental design. You build a prototype, see if it
>>works, tweak it a little, and repeat over many iterations.
>>
> 
> 
> As opposed to, say, thinking it through carefully and getting it right
> the first time?
> 
> John

I found that when I wrote a version of code that I intend to discard, I 
got a good product more quickly. I couldn't often do that because some 
stupid boss type was too likely ti insist that it be "shipped", so I had 
to work everything out in my head, on the sly, or at home.

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

Responding to Jjlindula@hotmail.com wrote:

> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.

The short answer is: use a good suite of development methodology. 
Almost all software development methodologies and processes provide 
"canned" mechanisms that are expressly designed to manage complexity. 
(Those that don't are missing the point.)

At the megathinker level there are four major ways to manage complexity. 
  One is divide-and-conquer where one subdivides large tasks into 
smaller tasks that are easier to address individually.  The functional 
decomposition from SA/SD was a classic example of this.

The second way is through separation of concerns.   This is a refinement 
of divide-and-conquer where one thinks in terms of subject matters 
rather than functionality.  One tries to identify and isolate problem 
spaces so that they can be coherently attacked independently. 
Systematic application partitioning is a classic example of this sort of 
thing.  [See the Application Partitioning category of my blog.]

The third way is through abstraction.  This is a uniquely OO tool that 
allows one to selectively ignore and emphasize different aspects of the 
problem.  Abstraction allows one to form different views of the problem 
space for different solution contexts.  That manages complexity by 
focusing on essential elements of context.

The fourth way is by extracting invariants from the problem space, 
encoding them in software, and leaving detailed differences to 
configuration data via parametric polymorphism.  This is a 
specialization of abstraction where one tries to ferret out the 
fundamentals of the problem and convert details into a data management 
problem.  [See the category Invariants and Parametric Polymorphism on my 
blog.]

However, as I indicated in the opening, if one follows a good A&D 
methodology, one gets techniques for doing these things "for free".

<Apocryphal anecdote>
Years ago at a social gathering I met a guy and, when he found out I did 
OO software development, the conversation went something like this...

He: we are converting to OO to re-develop an 18 MLOC system from the 
ground up.

Me: Great.  What methodology are you using?

He (looking at me as if discovering I had Alzheimer's): Uh... you know. 
  objects...C++...all that stuff.

Me: I mean, what analysis and design methodology will you be following?

He: Uh, I'm not sure.  We just had a 1-week course on C++.  So it is 
whatever one they used.

Me:  Hmmm.  Do you have any experienced OO people in your shop?

He: A couple of recent June Grads had C++ courses in school.

Me: Hmmm.  How much consulting and mentoring are you going to get?

He: Just the C++ course.  And, of course, the book that came with the 
course.

Me: Well, good luck.

Now I don't know whether that project has crashed and burned yet, but if 
it hasn't I am sure it will; the only issue is the size of the crater it 
will make.  Alas, it will probably be chalked up to yet another OO failure.
</apochryphal anecdote>

> As an engineer, I'm constantly trying to improve my design processes.

Definitely the right attitude.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Fred Marshall skrev:
> <jjlindula@hotmail.com> wrote in message
> news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> > Hello, I'm interested in how individuals or design groups manage
> > complexity in their design projects. What things do you do or things
> > the group does that can take complex tasks and break them into simpler
> > or more manageable tasks? It may sound like a weird question, but there
> > must be some guidelines, best practices, or habits used to achieve
> > success in designing/developing a complex project. I'm sure there must
> > be some individuals out there that are constantly taking complex tasks
> > and just about every time have success with it. Short of speaking, I
> > want to know what's the secret to their success. All comments are
> > welcomed, even the most obvious suggestions.
> >
> > As an engineer, I'm constantly trying to improve my design processes.
> >
>
> Joe,
>
> Here is another perspective:
>
> People are the source of complexity.

I'd say some problems are complex before adding the people factor.

> Better" is the enemy of "good enough".

Hmm... I've seen this in the form "'perfect' is the enemy of 'good
enough'", which I agree with. I am not sure I agree with "'better'...".


> One reason the requirements need to be understood is to avoid changes.
>
> 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 made the mistake some time ago to browse through a book on project
management (don't remember the title, though). As far as I remember,
there were four basic modes of project planning:

A) Goals fixed, resources fixed.
B) Goals fixed, resources relaxed[*]
C) Goals relaxed[*], resources fixed
D) Goals relaxed[*], resources relaxed[*]

[*] "relaxed" means that the goals or resources either are unknown
at project planning time, or they change significantly troughout
project lifetime.

While no one knows everything that will happen in the future, I do
agree with you that changes in goals should be avoided, as far as
possible, during project lifetime. I was not happy to discover the
emphasis on cases C) and D) above, in the book I browsed. Perhaps
I am too naive?

> It doesn't happen often that it isn't, but try to make sure that the thing
> is feasible in our lifetime - otherwise it isn't engineering it's an
> experiment.

Agreed.

> Sometimes you won't know the requirements until you've tried some things.

Would this type of project qualify as cases C)-D) above?

Rune

Rune Allnor wrote:
> 
> Fred Marshall skrev:
> 
>><jjlindula@hotmail.com> wrote in message
>>news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
>>
>>>Hello, I'm interested in how individuals or design groups manage
>>>complexity in their design projects. What things do you do or things
>>>the group does that can take complex tasks and break them into simpler
>>>or more manageable tasks? It may sound like a weird question, but there
>>>must be some guidelines, best practices, or habits used to achieve
>>>success in designing/developing a complex project. I'm sure there must
>>>be some individuals out there that are constantly taking complex tasks
>>>and just about every time have success with it. Short of speaking, I
>>>want to know what's the secret to their success. All comments are
>>>welcomed, even the most obvious suggestions.
>>>
>>>As an engineer, I'm constantly trying to improve my design processes.
>>>
>>
>>Joe,
>>
>>Here is another perspective:
>>
>>People are the source of complexity.
> 
> 
> I'd say some problems are complex before adding the people factor.
> 
> 
>>Better" is the enemy of "good enough".
> 
> 
> Hmm... I've seen this in the form "'perfect' is the enemy of 'good
> enough'", which I agree with. I am not sure I agree with "'better'...".
> 
> 
> 
>>One reason the requirements need to be understood is to avoid changes.
>>
>>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 made the mistake some time ago to browse through a book on project
> management (don't remember the title, though). As far as I remember,
> there were four basic modes of project planning:
> 
> A) Goals fixed, resources fixed.
> B) Goals fixed, resources relaxed[*]
> C) Goals relaxed[*], resources fixed
> D) Goals relaxed[*], resources relaxed[*]
> 
> [*] "relaxed" means that the goals or resources either are unknown
> at project planning time, or they change significantly troughout
> project lifetime.
> 
> While no one knows everything that will happen in the future, I do
> agree with you that changes in goals should be avoided, as far as
> possible, during project lifetime. I was not happy to discover the
> emphasis on cases C) and D) above, in the book I browsed. Perhaps
> I am too naive?
> 
> 
>>It doesn't happen often that it isn't, but try to make sure that the thing
>>is feasible in our lifetime - otherwise it isn't engineering it's an
>>experiment.
> 
> 
> Agreed.
> 
> 
>>Sometimes you won't know the requirements until you've tried some things.
> 
> 
> Would this type of project qualify as cases C)-D) above?

In some fields, it's typical. If you can specify the outcome and the 
path to it, it isn't research.

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

Jerry Avins skrev:
> Rune Allnor wrote:
> >
> > Fred Marshall skrev:
> >>Sometimes you won't know the requirements until you've tried some things.
> >
> >
> > Would this type of project qualify as cases C)-D) above?
>
> In some fields, it's typical. If you can specify the outcome and the
> path to it, it isn't research.

Ah, sorry. I didn't mention that these cases applied to projects in
general, not necessarily R&D projects. R&D comes into case C) and D)
almost by default.

Rune

In comp.arch.fpga,comp.software-eng and comp.dsp, On 21 Jul 2005
11:21:05 -0700, "jjlindula@hotmail.com" <jjlindula@hotmail.com> wrote:

>Hello, I'm interested in how individuals or design groups manage
>complexity in their design projects. What things do you do or things
>the group does that can take complex tasks and break them into simpler
>or more manageable tasks? It may sound like a weird question, but there
>must be some guidelines, best practices, or habits used to achieve
>success in designing/developing a complex project. I'm sure there must
>be some individuals out there that are constantly taking complex tasks
>and just about every time have success with it. Short of speaking, I
>want to know what's the secret to their success. All comments are
>welcomed, even the most obvious suggestions.
>
>As an engineer, I'm constantly trying to improve my design processes.

   The big company I worked for at the time sent me to a week-long
"Software Engineering Training Program" while in the middle of a
longish project. I recall it being a mostly "positive learning
experience" but the only thing I now (10 years later) remember from it
was "Do a post-mortem on the project." When you get done with a
project (whether it's shipping or it was trashed), you (meaning the
whole team) look it over (perhaps not so much the design itself but
rather how you did it), see what you did right and what went wrong,
what you could have done better, etc. The point of this is that you
might have better insight at the start of the next project, rather
than at the end of it.
   Of course, at the end of the project I was working on, we did NOT
do a post-mortem.

>Thanks everyone,
>joe

-----
http://www.mindspring.com/~benbradley

Ben Bradley wrote:
> 
>    The big company I worked for at the time sent me to a week-long
> "Software Engineering Training Program" while in the middle of a
> longish project. I recall it being a mostly "positive learning
> experience" but the only thing I now (10 years later) remember from it
> was "Do a post-mortem on the project." When you get done with a
> project (whether it's shipping or it was trashed), you (meaning the
> whole team) look it over (perhaps not so much the design itself but
> rather how you did it), see what you did right and what went wrong,
> what you could have done better, etc. The point of this is that you
> might have better insight at the start of the next project, rather
> than at the end of it.
>    Of course, at the end of the project I was working on, we did NOT
> do a post-mortem.

Very common.

I was involved in one of those hellish development projects that 
resembles a slow moving train wreck.

The project was supposed to take 9 months but ended up taking over
2.5 years. Near the end, I offered to write a paper on what went
wrong and how to avoid similar problems in future projects. I made
it clear that I was not looking to blame anyone but I wanted the
company and the development team to learn from the mistakes made.

My offer was ignored and I left the company 4 months later to
go to a job with about 5% less pay.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold"  -- Bobby D. Bryant

<jjlindula@hotmail.com> wrote in message 
news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks?

Easy:

1) Make sure the chief architect or engineer is responsible for getting the 
project delivered on time.

2) Make sure he doesn't have enough time to do too much of the work himself.

3) Make sure there are enough other resources available to make it worth his 
while to take advantage of them.

Then, the chief architect or engineer will have to divide much of the 
project into manageable components that can be assigned to others.

--
Matt

Erik de Castro Lopo wrote:
> I was involved in one of those hellish development projects that 
> resembles a slow moving train wreck.

Only one? Your career must have been truly blessed. :-)

Steve

Steve Underwood wrote:
> 
> Erik de Castro Lopo wrote:
> > I was involved in one of those hellish development projects that
> > resembles a slow moving train wreck.
> 
> Only one? Your career must have been truly blessed. :-)

Well after that disaster I spent three and a half years doing technical 
support in the most senior level of support at SUN Microsystem.

I'm now back doing development work and find that things haven't
changed much :-).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I don't think any MS Exec will ever die of old age. Satan
doesn't need the competition."
-- Digital Wokan on LinuxToday.com

Rune Allnor wrote:

> While no one knows everything that will happen in the future, I do
> agree with you that changes in goals should be avoided, as far as
> possible, during project lifetime.

But there is a significant class of projects - at least in failure
visibility - where you beforehand can be practically certain that the
goals will change during the project lifetime: Projects which shold
manage public sector policies (i.e. payment of unemployment benefits,
health insurance, taxes, ...)

Greetings,

Jacob

PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
    and "comp.dsp"?
-- 
�What fun is it being "cool" if you can't wear a sombrero?�

Jacob Sparre Andersen skrev:
> Rune Allnor wrote:
>
> > While no one knows everything that will happen in the future, I do
> > agree with you that changes in goals should be avoided, as far as
> > possible, during project lifetime.
>
> But there is a significant class of projects - at least in failure
> visibility - where you beforehand can be practically certain that the
> goals will change during the project lifetime: Projects which shold
> manage public sector policies (i.e. payment of unemployment benefits,
> health insurance, taxes, ...)

Do such activities satisfy the definition of of a project?
As far as I remember, a project is defined as something like

"An activity with a priori specified goals and resources,
that takes place once, and that is of limited duration."

The activites you describe seem to be programs, to me. Somehow,
I have the impression that the words "project" and "activity"
are on their way to become synonyms.

I prefer to stick to the definition of a project, with a priori
known goals and resources, and handle the changes as "deviations
from plans". Labeling the changes like that, may put some pressure
on planners to get their estimates right the next time, or make
them choose to organize the activity as something other than a
project.

> PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
>     and "comp.dsp"?

I don't know about comp.arch.fpga, but the last few weeks the
threads on comp.dsp have not been all that on-topic, not least
thanks to me.

Every now and then, threads of more "philosophical" nature occur.
I think project organization and company policy are very important
parts of engineering projects these days. Every now and then,
such questions, rather than technology, are the roots of the
problems. I don't necessarily see this thread as off topic, what
comp.dsp is concerned.

But then, I'm a major contributor to the noise on comp.dsp.

> =BBWhat fun is it being "cool" if you can't wear a sombrero?=AB

Indeed.

Rune

Erik de Castro Lopo wrote:
(snip)

> I was involved in one of those hellish development projects that 
> resembles a slow moving train wreck.

> The project was supposed to take 9 months but ended up taking over
> 2.5 years. Near the end, I offered to write a paper on what went
> wrong and how to avoid similar problems in future projects. I made
> it clear that I was not looking to blame anyone but I wanted the
> company and the development team to learn from the mistakes made.

Read "Mythical man-month", which pretty much has the same description,
though on a different scale.

It is written by the head of the OS/360 project.  The examples relate
to software projects, but it should be more generally applicable.

-- glen

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1122079067.583190.317210@o13g2000cwo.googlegroups.com...
>
>
> Jerry Avins skrev:
>> Rune Allnor wrote:
>> >
>> > Fred Marshall skrev:
>> >>Sometimes you won't know the requirements until you've tried some 
>> >>things.
>> >
>> >
>> > Would this type of project qualify as cases C)-D) above?
>>
>> In some fields, it's typical. If you can specify the outcome and the
>> path to it, it isn't research.
>
> Ah, sorry. I didn't mention that these cases applied to projects in
> general, not necessarily R&D projects. R&D comes into case C) and D)
> almost by default.
>
> Rune
>

Yeah, I thought we were talking about projects that result in a product of 
some sort.  Now, research results would be a "product" to a researcher but I 
was thinking in terms of "harder" deliverables: a system, a box, an 
application program, etc.  So, research papers weren't in my frame of 
reference as a "product".  Engineeers do research but is research 
"engineering"?  A narrower definition for engineering is to "build" 
something (as in design, build, test).  A definition from the web:
  1.. The application of scientific and mathematical principles to practical 
ends such as the design, manufacture, and operation of efficient and 
economical structures, machines, processes, and systems.
I thought that was the context and perhaps beyond into "project management".

So, when we are engineering something, sometimes we have to do a little 
research along the way and that was the crux of "sometimes you don't know 
the requirements until you've tried something".  But, at that, I think this 
is about finding out how certain things interact or behave that require some 
experimentation but I don't think of that as "research" as such.  I can 
think of lots of examples in real life.

Here's an example:
An underwater vehicle that looks like a torpedo would be launched and would 
deploy a towed array rather immediately after launch.  The vehicle was 
controlled by a circular shroud at the tail around the propellors that would 
move up/down port/starboard.  The tow cable was wrapped around the shroud 
and held in place with some hardware claptrap.
The idea was that the claptrap would be released, the flow of water would 
pull it aft and away.  The cable would deploy and the control surface would 
be free to move.
When it failed to work that way, not only did the cable not deploy but the 
vehicle had no dynamic control.
Off to the water tunnel....
It became apparent that the flow of water over the tail cone had velocity 
not only aft but *toward* the skin of the vehicle.  It pressed the claptrap 
*toward* the tail cone - which was in direct opposition to the force needed 
for it to deploy.

.... that was an experiment to support development but it wasn't research. 
The result changed the specifications for the claptrap and its release 
mechanisms.

....shake, rattle and roll testing often ends up with new requirements on the 
design unless the designers are very experienced.  That's probably a good 
example.

Once I managed a project that had the purpose of "developing technology" - 
which meant that we were trying new ideas for known end applications within 
a system context.  Now that was somewhat researchy and was certainly 
development.  Having best practices regarding how to do research yields a 
different set of suggestions doesn't it?

Here's an example:
We were trying to reduce the drag of underwater vehicles using all sorts of 
very high tech methods.  One of the groups (no doubt with a vested interest) 
reported experimental success of their technique.  But, some the of the 
tests had failed.  When asked why they threw out those results, they said: 
"something must have been wrong and invalidated those tests".  But, they had 
no idea what might have been wrong or if the tests were truly invalid.  In 
the end we decided that the technology lacked robustness and the results 
were valid: they were indicative of a technology that was "on the edge" of 
working or not working.

So, for research we add to best practices: design of experiments, how to 
handle results, repeatability, etc.

Fred 

Fred Marshall skrev:
> "Rune Allnor" <allnor@tele.ntnu.no> wrote in message
> news:1122079067.583190.317210@o13g2000cwo.googlegroups.com...
> >
> >
> > Jerry Avins skrev:
> >> Rune Allnor wrote:
> >> >
> >> > Fred Marshall skrev:
> >> >>Sometimes you won't know the requirements until you've tried some
> >> >>things.
> >> >
> >> >
> >> > Would this type of project qualify as cases C)-D) above?
> >>
> >> In some fields, it's typical. If you can specify the outcome and the
> >> path to it, it isn't research.
> >
> > Ah, sorry. I didn't mention that these cases applied to projects in
> > general, not necessarily R&D projects. R&D comes into case C) and D)
> > almost by default.
> >
> > Rune
> >
>
> Yeah, I thought we were talking about projects that result in a product of
> some sort.  Now, research results would be a "product" to a researcher but I
> was thinking in terms of "harder" deliverables: a system, a box, an
> application program, etc.  So, research papers weren't in my frame of
> reference as a "product".  Engineeers do research but is research
> "engineering"?  A narrower definition for engineering is to "build"
> something (as in design, build, test).  A definition from the web:
>   1.. The application of scientific and mathematical principles to practical
> ends such as the design, manufacture, and operation of efficient and
> economical structures, machines, processes, and systems.
> I thought that was the context and perhaps beyond into "project management".
>
> So, when we are engineering something, sometimes we have to do a little
> research along the way and that was the crux of "sometimes you don't know
> the requirements until you've tried something".  But, at that, I think this
> is about finding out how certain things interact or behave that require some
> experimentation but I don't think of that as "research" as such.

How would you prepare for such a project, if you were to take on
something you knew/suspected would need to break new ground? Divide it
into lots of small projects, where one could decide whether to proceed
or not, after each sub-project? Allocate large fractions (25% - 50%)
of the budget to "unexpected expenses"?

>  I can
> think of lots of examples in real life.
>
> Here's an example:
> An underwater vehicle that looks like a torpedo would be launched and would
> deploy a towed array rather immediately after launch.  The vehicle was
> controlled by a circular shroud at the tail around the propellors that would
> move up/down port/starboard.  The tow cable was wrapped around the shroud
> and held in place with some hardware claptrap.
> The idea was that the claptrap would be released, the flow of water would
> pull it aft and away.  The cable would deploy and the control surface would
> be free to move.
> When it failed to work that way, not only did the cable not deploy but the
> vehicle had no dynamic control.
> Off to the water tunnel....
> It became apparent that the flow of water over the tail cone had velocity
> not only aft but *toward* the skin of the vehicle.  It pressed the claptrap
> *toward* the tail cone - which was in direct opposition to the force needed
> for it to deploy.
>
> ... that was an experiment to support development but it wasn't research.
> The result changed the specifications for the claptrap and its release
> mechanisms.

I'd say this example involves "unexpected expenses". The goal, to make
this device work, has not changed. Getting it to work, takes a little
bit longer and involves more cost than previously anticipated.

> ...shake, rattle and roll testing often ends up with new requirements on the
> design unless the designers are very experienced.  That's probably a good
> example.

I can see how the design requirements are refined or adjusted, as
experience is gained. But do the goals change? Perhaps we are splitting

hairs here, but I don't see that they do.

> Once I managed a project that had the purpose of "developing technology" -
> which meant that we were trying new ideas for known end applications within
> a system context.  Now that was somewhat researchy and was certainly
> development.  Having best practices regarding how to do research yields a
> different set of suggestions doesn't it?

The goals for that kind of project are not easy to measure/quantify.
"You are two weeks late on the breakthrough idea!" Can't really see
that happening... ;)

> Here's an example:
> We were trying to reduce the drag of underwater vehicles using all sorts of
> very high tech methods.  One of the groups (no doubt with a vested interest)
> reported experimental success of their technique.  But, some the of the
> tests had failed.  When asked why they threw out those results, they said:
> "something must have been wrong and invalidated those tests".  But, they had
> no idea what might have been wrong or if the tests were truly invalid.  In
> the end we decided that the technology lacked robustness and the results
> were valid: they were indicative of a technology that was "on the edge" of
> working or not working.

These are questions of craftmanship, regardless of whether we define
this as an engineering or R&D project. If you do a set of tests, there
are certain standards one would like to keep in order to "sell" the
results. Explaining large amounts of "anomalies" should include a
discussions of reasons, including the possible non-robust method.

A few years ago, I met a former colleague who had got a new job in a
company dealing with marine operations, since I last met him. He
described a project he was involved in, where they had as ambition to
deploy certain types of kit at the sea floor, at given locations in the

deep sea and with very high accuracy. As he finished describing the
goals,
my reaction, expressed as a combination of body language and verbal
comments was to the effect of "You guys must be mad to attempt
something
like this!" "Oh yes, that's how it might look." he responded. "We don't

expect to actually meet the ambitions, though, but we would like
to see how close we can get, and what it takes to get there."
Most reassuring.

We went on to discuss various ways of getting close to these goals.
My friend said that somebody from some service company had approached
him to discuss methods to deploy the kit. The people from the service
company had said they could do this with standard technology. "Do you
believe they can?" I asked quietly. "No. The representatives didn't
even blink an eye when I described our ambitions."

Our unspoken mutual understanding was that anyone who understood the
complexity (well, semi-sanity) of the stated goals, would be very
sceptical to whether this was at all possible. The service company
showed, as I understood my friend's tale, no signs of understanding
what this was all about, and did thus not get the contract.

> So, for research we add to best practices: design of experiments, how to
> handle results, repeatability, etc.

Exactly. To me, these aspects are embedded in the term "craftmanship".

Rune

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message 
news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net...

> One reason the requirements need to be understood is to avoid changes.
>
> You should have a process to prevent changes.

ACK!

Preventing changes, the good old "requirements freeze" is a sure way to kill 
a project.

Requirements are going to change.  To pretend otherwise is just putting your 
head in the sand.  The name of the game is to manage the requirements.  For 
some reason, many software professionals seem to believe that "requirements 
management" is the same as requirements elicitation, but there is a bunch 
more than that.

You need to understand the impact of requirements changes, and deal with 
them.  Yes, some changes should be resisted.  Requirements changes that will 
significantly affect the development effort must be identified, and then the 
effort re-sized.  That may mean renegotiation.  The renegotiation may cause 
the customer to re-think how urgent the change is, or not.  Most 
requirements changes, though, are not of that nature. Most are probably just 
refinements of our understanding of the requirements.  Usually, we try to 
pretend that these are not changes by simply not documenting them.  That way 
we'll have to re-learn them.  Other times we discover that we misunderstood 
the requirement in the first place.  Well, recognize that as soon as 
possible when it has the minimum impact, and recognize the impact.

Requirements management isn't easy, but it's not a black art either.  It's 
mostly about keeping your eyes wide open.

...

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" <allnor@tele.ntnu.no> wrote in message 
news:1122167921.820607.126720@g47g2000cwa.googlegroups.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.

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1122157921.866725.149310@g44g2000cwa.googlegroups.com...
>
>
> Fred Marshall skrev:
>> "Rune Allnor" <allnor@tele.ntnu.no> wrote in message
>> news:1122079067.583190.317210@o13g2000cwo.googlegroups.com...
>> >
>> >
>> > Jerry Avins skrev:
>> >> Rune Allnor wrote:
>> >> >
>> >> > Fred Marshall skrev:
>> >> >>Sometimes you won't know the requirements until you've tried some
>> >> >>things.
>> >> >
>> >> >
>> >> > Would this type of project qualify as cases C)-D) above?
>> >>
>> >> In some fields, it's typical. If you can specify the outcome and the
>> >> path to it, it isn't research.
>> >
>> > Ah, sorry. I didn't mention that these cases applied to projects in
>> > general, not necessarily R&D projects. R&D comes into case C) and D)
>> > almost by default.
>> >
>> > Rune
>> >
>>
>> Yeah, I thought we were talking about projects that result in a product 
>> of
>> some sort.  Now, research results would be a "product" to a researcher 
>> but I
>> was thinking in terms of "harder" deliverables: a system, a box, an
>> application program, etc.  So, research papers weren't in my frame of
>> reference as a "product".  Engineeers do research but is research
>> "engineering"?  A narrower definition for engineering is to "build"
>> something (as in design, build, test).  A definition from the web:
>>   1.. The application of scientific and mathematical principles to 
>> practical
>> ends such as the design, manufacture, and operation of efficient and
>> economical structures, machines, processes, and systems.
>> I thought that was the context and perhaps beyond into "project 
>> management".
>>
>> So, when we are engineering something, sometimes we have to do a little
>> research along the way and that was the crux of "sometimes you don't know
>> the requirements until you've tried something".  But, at that, I think 
>> this
>> is about finding out how certain things interact or behave that require 
>> some
>> experimentation but I don't think of that as "research" as such.
>
> How would you prepare for such a project, if you were to take on
> something you knew/suspected would need to break new ground? Divide it
> into lots of small projects, where one could decide whether to proceed
> or not, after each sub-project? Allocate large fractions (25% - 50%)
> of the budget to "unexpected expenses"?

I guess you might budget a lot for unexpected expenses.  But, I didn't think 
we were talking here so much about project management as about best 
practices in development.  Frankly I'd not be too comfortable with such an 
allocation *if* cost and schedule were paramount - which they often are.

Maybe you could break things down into smaller pieces and maybe not.  The 
notion is a good one to be sure - but agreeing or disagreeing in such 
general terms is too speculative for me.  Maybe that's the essence of 
"complex" - that something hasn't been well partitioned and organized, eh?

I can imagine control systems engineering as dealing with things that are 
complex and making them simpler by virtue of the tools.  Once you know about 
the tools then most things in this context are perceived as simpler aren't 
they?  That doesn't make them easier to deal with "seat of the pants" - but 
knowing that the tools are there and what they do, etc. makes things appear 
to be simpler.  Computers are great for keeping track of a lot of things at 
once - much better than humans.

We designed a control system for a semisubmersible oil and gas production 
platform in Sweden.  The thing had over 50 ballast tanks that we would 
control with a computer program (model, etc.).  When it went to sea the crew 
tried to trim the tanks by hand and were never able to level the platform. 
Eventually they decided to try out the new-fangled computer thingy and the 
platform leveled out directly.  The task was too *complex* for humans unless 
they used the computer controls and then the task was made simple for them. 
They were incapable of dealing with all the subsystems and their 
interactions.  Too many subsystems and too many interactions.  So, breaking 
it into smaller parts wasn't the solution.

>
>>  I can
>> think of lots of examples in real life.
>>
>> Here's an example:
>> An underwater vehicle that looks like a torpedo would be launched and 
>> would
>> deploy a towed array rather immediately after launch.  The vehicle was
>> controlled by a circular shroud at the tail around the propellors that 
>> would
>> move up/down port/starboard.  The tow cable was wrapped around the shroud
>> and held in place with some hardware claptrap.
>> The idea was that the claptrap would be released, the flow of water would
>> pull it aft and away.  The cable would deploy and the control surface 
>> would
>> be free to move.
>> When it failed to work that way, not only did the cable not deploy but 
>> the
>> vehicle had no dynamic control.
>> Off to the water tunnel....
>> It became apparent that the flow of water over the tail cone had velocity
>> not only aft but *toward* the skin of the vehicle.  It pressed the 
>> claptrap
>> *toward* the tail cone - which was in direct opposition to the force 
>> needed
>> for it to deploy.
>>
>> ... that was an experiment to support development but it wasn't research.
>> The result changed the specifications for the claptrap and its release
>> mechanisms.
>
> I'd say this example involves "unexpected expenses". The goal, to make
> this device work, has not changed. Getting it to work, takes a little
> bit longer and involves more cost than previously anticipated.

The point was whether it was development or "research" - not that it cost a 
bit more to accomplish.

>
>> ...shake, rattle and roll testing often ends up with new requirements on 
>> the
>> design unless the designers are very experienced.  That's probably a good
>> example.
>
> I can see how the design requirements are refined or adjusted, as
> experience is gained. But do the goals change? Perhaps we are splitting
>
> hairs here, but I don't see that they do.

I agree that the goals don't change.  The point was that some try/fix 
process was likely.

>
>> Once I managed a project that had the purpose of "developing 
>> technology" -
>> which meant that we were trying new ideas for known end applications 
>> within
>> a system context.  Now that was somewhat researchy and was certainly
>> development.  Having best practices regarding how to do research yields a
>> different set of suggestions doesn't it?
>
> The goals for that kind of project are not easy to measure/quantify.
> "You are two weeks late on the breakthrough idea!" Can't really see
> that happening... ;)

In this case the schedule was fixed for a wide array of technologies. 
Either things panned out in time or they didn't.  If someone was trying to 
make too great a breakthrough then they would probably fail.  That was OK 
because the next step was to take the best, proven technologies and build 
something real.  Nobody in their right mind would start a product 
development with an unproven technology while there were proven technologies 
available.

The goals were easy to measure and quantify.  Either the technology appeared 
to work well or it didn't or it never really got off the ground.  The next 
phase of system development would decide which technologies really made 
sense.

(In the end, some technologies were carried a bit too far into development - 
for reasons that seemed good at the time but were really more emotional than 
real.  "High risk, high payoff" turned out to be really "high risk, very 
modest payoff".  In the end, money determined the best approach - which was 
the right outcome).

>
>> Here's an example:
>> We were trying to reduce the drag of underwater vehicles using all sorts 
>> of
>> very high tech methods.  One of the groups (no doubt with a vested 
>> interest)
>> reported experimental success of their technique.  But, some the of the
>> tests had failed.  When asked why they threw out those results, they 
>> said:
>> "something must have been wrong and invalidated those tests".  But, they 
>> had
>> no idea what might have been wrong or if the tests were truly invalid. 
>> In
>> the end we decided that the technology lacked robustness and the results
>> were valid: they were indicative of a technology that was "on the edge" 
>> of
>> working or not working.
>
> These are questions of craftmanship, regardless of whether we define
> this as an engineering or R&D project. If you do a set of tests, there
> are certain standards one would like to keep in order to "sell" the
> results. Explaining large amounts of "anomalies" should include a
> discussions of reasons, including the possible non-robust method.
>
> A few years ago, I met a former colleague who had got a new job in a
> company dealing with marine operations, since I last met him. He
> described a project he was involved in, where they had as ambition to
> deploy certain types of kit at the sea floor, at given locations in the
>
> deep sea and with very high accuracy. As he finished describing the
> goals,
> my reaction, expressed as a combination of body language and verbal
> comments was to the effect of "You guys must be mad to attempt
> something
> like this!" "Oh yes, that's how it might look." he responded. "We don't
>
> expect to actually meet the ambitions, though, but we would like
> to see how close we can get, and what it takes to get there."
> Most reassuring.
>
> We went on to discuss various ways of getting close to these goals.
> My friend said that somebody from some service company had approached
> him to discuss methods to deploy the kit. The people from the service
> company had said they could do this with standard technology. "Do you
> believe they can?" I asked quietly. "No. The representatives didn't
> even blink an eye when I described our ambitions."
>
> Our unspoken mutual understanding was that anyone who understood the
> complexity (well, semi-sanity) of the stated goals, would be very
> sceptical to whether this was at all possible. The service company
> showed, as I understood my friend's tale, no signs of understanding
> what this was all about, and did thus not get the contract.
>
>> So, for research we add to best practices: design of experiments, how to
>> handle results, repeatability, etc.
>
> Exactly. To me, these aspects are embedded in the term "craftmanship".

I agree. It was just that the original question was about best practices for 
development and not for research.  So, the responses were about development. 
Then Jerry brought up "research" and we started a bit down that path.  I 
simply tried to say that changing the question would change at least some of 
the answers.  It's a bit harder for me to envision a product engineering 
team deciding that failed tests were actually "OK" - although I know that it 
happens.  (e.g. see Richard Feynman's treatment of the space shuttle 
disaster.  Thus, I say "harder" not impossible).

Maybe there needs to be another item on the list:
"Make sure there is good craftsmanship in every discipline"

Fred 

"xpyttl" <xpyttl_NOSPAM@earthling.net> wrote in message 
news:IWAEe.15990$bG4.3120@fe06.lga...
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message 
> news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net...
>
>> One reason the requirements need to be understood is to avoid changes.
>>
>> You should have a process to prevent changes.
>
> ACK!
>
> Preventing changes, the good old "requirements freeze" is a sure way to 
> kill a project.
>

I'm sure we could argue about this forever.
I think it's mostly a matter of context.
One can just as easily say: "allowing changes is a sure way to kill a 
project".
Then, all you have to do is sort out what the heck either of us is talking 
about...
Because both perspectives are fine.

I once worked on a project where the box was going to be painted blue.  And 
then it was going to be painted silver.  And then it was going to be painted 
green.  So, we kept going to meetings and never finishing.  That's a good 
example for when a requirement should have been frozen.  At least it would 
have saved a lot of precious time!  It really didn't matter all that much 
but a lot of stuff was left hanging pending the decision on the color of the 
box!

Sure requirements change with new awareness, changed conditions, etc. 
Here's an example of how "new awareness" messed up a project:
We were building a processor-based system.  It was new technology.  The 
operating system had been selected and we were on a path to getting the 
system implemented.
Then, the principal in software went to a symposium and met a real OS guru. 
Actually our software principal was a guru in his own right.  Anyway, he 
came home convinced that our OS could have a much smaller footprint in 
memory.  He trashed everything that had been done and started over because 
it appeared that "better" was indeed better and "good enough" wasn't good 
enough.

........ and the project did not complete on time to matter.  It fell off the 
edge of the table.

Ever hear: "if it ain't broke don't fix it" ?  That's a design freeze and it 
makes sense.

Fred

"Jerry Avins" <jya@ieee.org> wrote in message 
news:Nf-dnavJit7de3_fRVn-ow@rcn.net...
> 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

"jjlindula@hotmail.com" <jjlindula@hotmail.com> writes:

> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.
>
> Thanks everyone,
> joe

Joe,

What a great question! As the responses have shown, you've really hit
a nerve with many engineers.

Some may have said some of this already, but allow me respond in my
own words.

1. Define the requirements. 

In performing this task, try not to think too much about the details
of how the requirements will be implemented. On the other hand,
knowledge of implementation and/or current capabilities will almost
certainly shape the requirements. For example, it would be silly to
require (at this time in history) the capabilities of a Pentium 4
processor at a power consumption of a microwatt.

3. Face the fact that if requirements are added (or changed in certain
ways), the schedule for the design WILL slip. 

4. Design from the top down. That is, begin the design decomposition
at the top level and then iteratively break the higher level blocks
into lower level blocks. AKA hierarchical design.

Something (at least for me) very interesting happens at this stage
of the design. I find that there are two tricks when defining blocks at 
a specific level that are almost contradictions. 

On one hand, it seems that a good design decomposition comes by doing
some "back-and-forth" between one level and the next lower level, or
maybe even two levels. 

On the other hand, it is necessary to discipline your mind to view the
design at the current level and avoid the tendency to "drop down" to
the lower levels, at least for a time.

It seems that by alternately viewing the design at the current level,
and then also skitting back and forth between levels and looking for
optimal configurations, you come out with the best design
decompositions.

Another set of ABSOLUTELY CRUCIAL guidelines at this stage, especially
when performing software design, is to partition the modules or blocks
such that you MAXIMIZE COHESION and REDUCE COUPLING. You can find a lot
of material on these two concepts, e.g.,

http://www.ugolandini.net/AccoppiamentoCoesioneE.html

5. Implement from the bottom up. 

6. Be patient. 

Waiting for a system to be properly designed will almost always be
more efficient (time-wise) than "waterfall development," i.e., the
type of development for impatient managers that want to see something
almost immediately.

My $0.02.
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

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" <allnor@tele.ntnu.no> wrote in message
> news:1122167921.820607.126720@g47g2000cwa.googlegroups.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

Randy Yates wrote:

> 6. Be patient.
>
> Waiting for a system to be properly designed will almost always be
> more efficient (time-wise) than "waterfall development," i.e., the
> type of development for impatient managers that want to see something
> almost immediately.

I disagree.  A better model (than either big up-front design or
waterfall), in software development, is the spiral / agile model of
development.   I've found this model to be excellent, especially when
the requirements change or are not fully elicited --- as they usually
are in the sorts of software I've developed (greenfield ones).

Big up-front design can be a killer when requirements change.  For some
reason, managers and customers seem to think that software can be
changed much more easily than mechanical systems... so they do.  The
trick is to figure out when they're really expressing a new
requirement, or just jumping on the latest Big Thing.

I wholeheartedly agree with your previous point of keeping this as
abstract as possible for as long as possible.  This really helps the
whole design and elicitation process.... without investing huge amounts
of effort in implementing something that is not critical to success.

Ciao,

Peter K.

Fred Marshall wrote:

   ...

> I agree. It was just that the original question was about best practices for 
> development and not for research.  So, the responses were about development. 
> Then Jerry brought up "research" and we started a bit down that path.  I 
> simply tried to say that changing the question would change at least some of 
> the answers.  It's a bit harder for me to envision a product engineering 
> team deciding that failed tests were actually "OK" - although I know that it 
> happens.  (e.g. see Richard Feynman's treatment of the space shuttle 
> disaster.  Thus, I say "harder" not impossible).
> 
> Maybe there needs to be another item on the list:
> "Make sure there is good craftsmanship in every discipline"

I didn't mean to sidetrack the discussion. My ought to have been more 
explicit: some exploration is inevitable for all but the most mundane 
projects. It surprises none of us that R&D has become a single concept. 
I recall choosing an ADC converter peripheral card with bipolar 
multiplexer whose specs suited the needs of a project well, only to find 
-- after the hardware was assembled and drivers written -- that 
dielectric storage in the holding capacitor made the sampler unable to 
follow the multiplexer at speeds well within the spec. Oops!

(That time, I didn't have to start over. I found and fixed the problem 
and told the manufacturer how. They issued a recall and change order.)

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

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" <jya@ieee.org> wrote in message 
> news:Nf-dnavJit7de3_fRVn-ow@rcn.net...
> 
>>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.
�����������������������������������������������������������������������

Peter K. wrote:
> Randy Yates wrote:
> 
> 
>>6. Be patient.
>>
>>Waiting for a system to be properly designed will almost always be
>>more efficient (time-wise) than "waterfall development," i.e., the
>>type of development for impatient managers that want to see something
>>almost immediately.
> 
> 
> I disagree.  A better model (than either big up-front design or
> waterfall), in software development, is the spiral / agile model of
> development.   I've found this model to be excellent, especially when
> the requirements change or are not fully elicited --- as they usually
> are in the sorts of software I've developed (greenfield ones).
> 
> Big up-front design can be a killer when requirements change.  For some
> reason, managers and customers seem to think that software can be
> changed much more easily than mechanical systems... so they do.  The
> trick is to figure out when they're really expressing a new
> requirement, or just jumping on the latest Big Thing.
> 
> I wholeheartedly agree with your previous point of keeping this as
> abstract as possible for as long as possible.  This really helps the
> whole design and elicitation process.... without investing huge amounts
> of effort in implementing something that is not critical to success.

I disagree with both of you. So there! (Disagreeing seems to be an 
activity that I do very well.) I could have written that you're both 
right. There are lots of models, and some people do better with one than 
with another. When the planning is up to you, but your boss picks the 
model, it's time to circulate your resume.

I have never found a model that works for me that I can explain. My most 
productive mode is sitting with my feet on the desk and my eyes closed 
for a long time, consult a data sheet on occasion, and after a day or so 
of seeming inactivity, write down a plan. At meetings, I can't be that 
thorough, so I would usually listen at least half way through, longer if 
politics allowed (the thought just happens), and the opine, "I would go 
about it this way ....") I used to get called to participate in planning 
meetings for projects we all knew I would have no further association 
with. My advice was often followed, and sometimes backed up to. That's 
not to brag (but I acknowledge the form!), but to illustrate that my 
amorphous approach worked for at least one person -- me.

I think it's good to know several planning paradigms, and to choose one 
that fits one's own style, and perhaps the project. As usual, the best 
way is acknowledging that there is no best way.

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

Jerry Avins skrev:
> There are lots of models, and some people do better with one than
> with another. When the planning is up to you, but your boss picks the
> model, it's time to circulate your resume.

Most certainly agreed.

> I have never found a model that works for me that I can explain. My most
> productive mode is sitting with my feet on the desk and my eyes closed
> for a long time, consult a data sheet on occasion, and after a day or so
> of seeming inactivity, write down a plan.

Whoa, you are fast! I used to spend weeks in that mode. I am sure I
would be the worst employer any "ambitious" boss could have, drinking
coffe, reading papers and chatting with co-workers for days on end.

No apparent activity, but if left alone (no bosses wanted to see
"progress"), I always delivered on time and according to spec.

> At meetings, I can't be that
> thorough, so I would usually listen at least half way through, longer if
> politics allowed (the thought just happens), and the opine, "I would go
> about it this way ....") I used to get called to participate in planning
> meetings for projects we all knew I would have no further association
> with. My advice was often followed, and sometimes backed up to. That's
> not to brag (but I acknowledge the form!), but to illustrate that my
> amorphous approach worked for at least one person -- me.

>From my experience, the truly amazing aspect in your story is that
you were allowed to go on in this way, and that others acted
constructively on you suggestions. This is the stage where the
"fast trackers" usually find they need to make their mark on a
project, and then do.

> I think it's good to know several planning paradigms, and to choose one
> that fits one's own style, and perhaps the project. As usual, the best
> way is acknowledging that there is no best way.

Rune

Rune Allnor skrev:
> Jerry Avins skrev:
> > There are lots of models, and some people do better with one than
> > with another. When the planning is up to you, but your boss picks the
> > model, it's time to circulate your resume.
>
> Most certainly agreed.
>
> > I have never found a model that works for me that I can explain. My most
> > productive mode is sitting with my feet on the desk and my eyes closed
> > for a long time, consult a data sheet on occasion, and after a day or so
> > of seeming inactivity, write down a plan.
>
> Whoa, you are fast! I used to spend weeks in that mode. I am sure I
> would be the worst employer

Make that "emplyee"

Rune

> any "ambitious" boss could have, drinking
> coffe, reading papers and chatting with co-workers for days on end.
>
> No apparent activity, but if left alone (no bosses wanted to see
> "progress"), I always delivered on time and according to spec.

Rune Allnor skrev:
> Rune Allnor skrev:
> > Jerry Avins skrev:
> > > There are lots of models, and some people do better with one than
> > > with another. When the planning is up to you, but your boss picks the
> > > model, it's time to circulate your resume.
> >
> > Most certainly agreed.
> >
> > > I have never found a model that works for me that I can explain. My most
> > > productive mode is sitting with my feet on the desk and my eyes closed
> > > for a long time, consult a data sheet on occasion, and after a day or so
> > > of seeming inactivity, write down a plan.
> >
> > Whoa, you are fast! I used to spend weeks in that mode. I am sure I
> > would be the worst employer
>
> Make that "emplyee"

Or better still, "employee"...

Rune

> > any "ambitious" boss could have, drinking
> > coffe, reading papers and chatting with co-workers for days on end.
> >
> > No apparent activity, but if left alone (no bosses wanted to see
> > "progress"), I always delivered on time and according to spec.

Rune Allnor wrote:

   ...

> From my experience, the truly amazing aspect in your story is that
> you were allowed to go on in this way, and that others acted
> constructively on you suggestions. This is the stage where the
> "fast trackers" usually find they need to make their mark on a
> project, and then do.

RCA Labs was a truly amazing place to work. In the midst of a research 
lab, I was a "consultant" whose contribution was making things work. My 
reputation was better than I deserved, but it (and three Outstanding 
Achievement Awards) gave me the freedom to act rationally. One of my 
suggestions, on controlling a machine vital to a high-priority project 
was turned town to my dismay. I wanted to use existing hardware (of my 
design, based on a Z-80) programmed in Forth. The project leader "knew" 
that success required a much faster machine (12 MHz 8086) programmed in 
C. He used Intel boards.

I couldn't let personality issues sink the project, and I had the 
freedom to do it my way on my own. He had a team of three programmers 
who worked on the code for 5 weeks while the electrical interface was 
being built to the various sensors, switches, air valves, and transport 
motors. I had the drawings for that and the specs for some of what the 
controller had to do. (I had, on request, designed some of the 
algorithms. That's another funny story.) I wrote the code to do the job. 
The drivers for digital I/O were part of my design for the controller, 
completed long since. After a time, the design specs were changed (a 
flaw had been found) and I updated my code. Even after the update, I had 
only about ten days invested in programming AND TESTING.

What happened when they first married computer to room-sized machine was 
a loud BANG as every relay and air cylinder was simultaneously actuated. 
Mercifully, a motor tried to run both clockwise and counterclockwise and 
blew the breaker. Still, some pushrods bent, and a few other pieces 
needed to be replaced. You see, the system had been designed by 
programmers, who naturally assumed that high must mean ON, and low must 
mean OFF. Hardware engineers design circuits to be active low, because 
I/O pins default to inputs on reset and remain high until programmed as 
outputs and then set low. Back to the drawing board! They changed the 
code, but I didn't have to. I had written it properly from the start and 
had a tech build a bank of inverters to match their wiring. Now I could 
discard the inverter board.

After two more weeks of testing and recompiling after the repairs, it 
became clear that they wouldn't meet the deadline. I was asked to pitch 
in and assist. I unplugged their controller and plugged in mine. It 
worked right off, proving once again that a 4-MHz Z-80 is fast enough 
for almost anything that moves, and that knowing every bit of the code, 
including the compiler and the monitor ROM is a great help in avoiding 
mistakes and finding them when they happen.

Three programmers working seven weeks didn't manage what I had done on 
my own in less than two. I'm not a fast programmer; I never was. I had 
several advantages, though. First, I had no one to argue with me about 
how to do it. (It's easy to reach a consensus alone. :-)) Second, I had 
experience writing software to do I/O to control hardware. I had even 
built an effective system to do that, and I used it for the project. The 
device drivers for it were bug free long before the project began. 
Third, I wrote in Forth, which let me test each code function -- rarely 
more than two lines -- as it was written, so that only correct functions 
were incorporated into subsequent code.

Anyhow, my point is that the Labs gave me the freedom to do things like 
that, and succeeding at them earned me the freedom to do even more. Very 
few engineers ever enjoy the luck that I had. I feel especially blessed.

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

Rune Allnor wrote:

   ...
> Make that "emplyee"

My boss once said that I was useless most of the time, but that once a 
month or so, I earned double a month's pay. I could never figure out why 
my raises weren't bigger.

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

Jerry Avins skrev:
[... great story snipped ...]
> Three programmers working seven weeks didn't manage what I had done on
> my own in less than two. I'm not a fast programmer; I never was. I had
> several advantages, though. First, I had no one to argue with me about
> how to do it. (It's easy to reach a consensus alone. :-)) Second, I had
> experience writing software to do I/O to control hardware. I had even
> built an effective system to do that, and I used it for the project. The
> device drivers for it were bug free long before the project began.
> Third, I wrote in Forth, which let me test each code function -- rarely
> more than two lines -- as it was written, so that only correct functions
> were incorporated into subsequent code.

You forgot your forth, and probably decisive, advantage: You knew all
aspects of the task.

I commented on it in my first post (and I think Fred hinted along
the same lines in one of his early posts), that one person must be
able to grasp the whole problem. You saw the potential trouble spots
beforehand and avoided them. The most efficient way to recover from
a problem is to avoid the problem in the first place. You knew the
hardware/software high/low conventions and so on. The other team
had to discover all that.

Of course, you had even more advantages in that you had designed
the rest of the system, so let's say you saved a week or so of
finding, reading and understanding the system spec.  

Rune

Jerry Avins <jya@ieee.org> writes:

> It's easy to reach a consensus alone. 

Oh, man, Jerry - you can say that again!
-- 
%  Randy Yates                  % "The dreamer, the unwoken fool - 
%% Fuquay-Varina, NC            %  in dreams, no pain will kiss the brow..."
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

"Jerry Avins" <jya@ieee.org> wrote in message 
news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
> 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" <bungalow_steve@yahoo.com> wrote in message 
news:1122179959.459049.317700@o13g2000cwo.googlegroups.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

Randy Yates wrote:

>Jerry Avins <jya@ieee.org> writes:
>
>  
>
>>It's easy to reach a consensus alone. 
>>    
>>
>
>Oh, man, Jerry - you can say that again!
>  
>
Oh what bliss. A man who's free of inner conflicts. I often vigorously 
disagree with myself - especially when my tongue is saying "eat that" 
while my brain is saying "now, just how many kilos did the bathroom 
scales show the other day?" :-)

As America's great philsopher G.W. Bush so wisely said "I have opinions 
of my own, strong opinions, but I don't always agree with them." :-)

Regards,
Steve

Matt Timmermans wrote:
> "steve" <bungalow_steve@yahoo.com> wrote in message 
> news:1122179959.459049.317700@o13g2000cwo.googlegroups.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.
�����������������������������������������������������������������������

Steve Underwood wrote:
> Randy Yates wrote:
> 
>> Jerry Avins <jya@ieee.org> writes:
>>
>>  
>>
>>> It's easy to reach a consensus alone.   
>>
>>
>> Oh, man, Jerry - you can say that again!
>>  
>>
> Oh what bliss. A man who's free of inner conflicts. I often vigorously 
> disagree with myself - especially when my tongue is saying "eat that" 
> while my brain is saying "now, just how many kilos did the bathroom 
> scales show the other day?" :-)
> 
> As America's great philsopher G.W. Bush so wisely said "I have opinions 
> of my own, strong opinions, but I don't always agree with them." :-)

Hey there! I said a consensus is easy to reach, not that every decision 
is easy.

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

On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
wrote:


>a prototype can quickly confirm the robustness of a design

Does this imply that the best way to find bugs is to test a prototype?

That's the Bill Gates methodology.


John

> >As opposed to, say, thinking it through carefully and getting it right
> >the first time?
> >
> >John
> >  
> >
> If you can think something through carefully and get it right first 
> time, without experimentation, you are either:
> 
> a) a genius who would make Newton look like a moron, or
> 
> b) doing something pretty trivial.
> 
> Regards,
> Steve

If you design a complex 10s Mgates system-on-chips where each of the
10s masks costs 100k$ and where each design iteration is many months
long, you'll be killed if you come w/ your experimentation approach. I
don't think it's trivial ; so I'll try to compete w/ Newton w/ my
small capabilities.

Why not carefully think about your implementation of the requested
features? Select the appropriate architecture from the very beginning
(and regarding the penalty if you didn't choose the right architecture
from the beginning, you should better carefully look at the features
you're looking for and in which direction they can develop), identify
the main technical risks and concentrate on a way to be sure that the
architectural choices + the main functions will be validated during
the first iteration and that all the debug functions are in place to
identify most of the bugs.

W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL
productivity has only slightly improved while in the mean time the
FPGA/ASIC density has drastically increased. HW is not SW. Any
design/experiment/update approach only leads to loss of time (and
therefore $).

Eric DELAGE wrote:

>>>As opposed to, say, thinking it through carefully and getting it right
>>>the first time?
>>>
>>>John
>>> 
>>>
>>>      
>>>
>>If you can think something through carefully and get it right first 
>>time, without experimentation, you are either:
>>
>>a) a genius who would make Newton look like a moron, or
>>
>>b) doing something pretty trivial.
>>
>>Regards,
>>Steve
>>    
>>
>
>If you design a complex 10s Mgates system-on-chips where each of the
>10s masks costs 100k$ and where each design iteration is many months
>long, you'll be killed if you come w/ your experimentation approach. I
>don't think it's trivial ; so I'll try to compete w/ Newton w/ my
>small capabilities.
>
>Why not carefully think about your implementation of the requested
>features? Select the appropriate architecture from the very beginning
>(and regarding the penalty if you didn't choose the right architecture
>from the beginning, you should better carefully look at the features
>you're looking for and in which direction they can develop), identify
>the main technical risks and concentrate on a way to be sure that the
>architectural choices + the main functions will be validated during
>the first iteration and that all the debug functions are in place to
>identify most of the bugs.
>
>W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL
>productivity has only slightly improved while in the mean time the
>FPGA/ASIC density has drastically increased. HW is not SW. Any
>design/experiment/update approach only leads to loss of time (and
>therefore $).
>  
>
So, you don't produce any models of the modules in your chips? You don't 
use any simulators to debug each modelled element of the design? You 
don't try to simulate the entire thing to the extent the available tools 
will permit?

I think perhaps you do. Clue: those models are prototypes, and those 
simulators are where you experiment with them. I really really doubt 
you'll get a big design right without using them effectively. Even if 
you can get the logic right at the first attempt, your timing 
constraints must be pretty loose if you don't need to try some 
experiments with simulators to check the critical paths are going to 
play nicely.

Chips tend to have clearer requirements than complete systems. Few 
complete systems of any complexity are implemented without changes in 
the requirements along the way. Attempts to resist such changes just 
increase the likelihood of the system being already obsolete, or just 
inappropriate, on completion. Experimental systems (either physical or 
simulations) available early are a powerful way to get the end users to 
really figure out what they want. Specification by simulation is the 
only way I've ever seen a spec produced that survived the implementation 
phase intact. It is still a strategy too rarely used, even though it was 
producing excellent results 20 years ago.

You write like you have a chip on your shoulder (pun partially intended) 
about software vs hardware work. You seem to assume I was writing from a 
software developer's point of view. If so, you were wrong. Most software 
developers generally don't have to worry too much about this stuff. With 
so many embedded systems now using flash, most software is fairly fluid 
even after the ship date. :-)

Regards,
Steve

On a sunny day (Mon, 25 Jul 2005 10:23:45 +0800) it happened Steve Underwood
<steveu@dis.org> wrote in <dc1ifi$cs2$1@home.itg.ti.com>:

>Oh what bliss. A man who's free of inner conflicts. I often vigorously 
>disagree with myself - especially when my tongue is saying "eat that" 
>while my brain is saying "now, just how many kilos did the bathroom 
>scales show the other day?" :-)
>
>As America's great philsopher G.W. Bush so wisely said "I have opinions 
You mean THIS philosopher:
 ftp://panteltje.com/Bush_a_man_without_vision.jpg 
 ?

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

Jerry Avins wrote:
> I disagree with both of you. So there! (Disagreeing seems to be an
> activity that I do very well.)

:-)

> I could have written that you're both
> right. There are lots of models, and some people do better with one than
> with another. When the planning is up to you, but your boss picks the
> model, it's time to circulate your resume.

Ya.  That's the truth.

> I have never found a model that works for me that I can explain. My most
> productive mode is sitting with my feet on the desk and my eyes closed
> for a long time, consult a data sheet on occasion, and after a day or so
> of seeming inactivity, write down a plan. At meetings, I can't be that
> thorough, so I would usually listen at least half way through, longer if
> politics allowed (the thought just happens), and the opine, "I would go
> about it this way ....") I used to get called to participate in planning
> meetings for projects we all knew I would have no further association
> with. My advice was often followed, and sometimes backed up to. That's
> not to brag (but I acknowledge the form!), but to illustrate that my
> amorphous approach worked for at least one person -- me.

That's great if you have the freedom to do it.  I've never had that
amount of freedom.  There's nearly always been someone breathing down
my neck wanting to me to communicate what's happening now, why it's
happening, when the next thing is happening.

For me, the big up-front approach has never given me the ammunition to
resolve those issues... it takes to long to "show" anything... and
then, when you do have something to show, it comes all at once, so the
neck-breathers ask "Why didn't you do that six months ago?!?!?!".  The
"trickle" approaches have allowed me time to set expectations (things
happen, early on, but not necessarily at a blinding pace, but they keep
happening).

> I think it's good to know several planning paradigms, and to choose one
> that fits one's own style, and perhaps the project. As usual, the best
> way is acknowledging that there is no best way.

:-) Definitely good advice.  I just like arguing. :-)

Ciao,

Peter K.

Jerry Avins wrote:

> Anyhow, my point is that the Labs gave me the freedom to do things like
> that, and succeeding at them earned me the freedom to do even more. Very
> few engineers ever enjoy the luck that I had. I feel especially blessed.

You should!  Great story, Jerry. :-)

Ciao,

Peter K.

On Sun, 24 Jul 2005 22:31:38 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
>wrote:
>
>
>>a prototype can quickly confirm the robustness of a design
>
>Does this imply that the best way to find bugs is to test a prototype?
>
>That's the Bill Gates methodology.

The Bill Gates methodology is to get someone else to pay you for the
privilege of testing your prototype.

Bob Perlman
Cambrian Design Works

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" <jya@ieee.org> wrote in message 
> news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
> 
>>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" <jya@ieee.org> wrote in message
news:8OOdnYevi6v6_3nfRVn-jw@rcn.net...
> 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.
>

I see the Design as a "paper prototype".    It's to test the design and see
if the design is coherent.  Looking for bugs comes at the code level.

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


"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:76u8e1t7eunkn4ml5ckoo0timribme9tgh@4ax.com...
> On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
> wrote:
>
>
> >a prototype can quickly confirm the robustness of a design
>
> Does this imply that the best way to find bugs is to test a prototype?
>
> That's the Bill Gates methodology.
>

On Mon, 25 Jul 2005 13:16:34 GMT, Bob Perlman
<bobsrefusebin@hotmail.com> wrote:

>On Sun, 24 Jul 2005 22:31:38 -0700, John Larkin
><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>>On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
>>wrote:
>>
>>
>>>a prototype can quickly confirm the robustness of a design
>>
>>Does this imply that the best way to find bugs is to test a prototype?
>>
>>That's the Bill Gates methodology.
>
>The Bill Gates methodology is to get someone else to pay you for the
>privilege of testing your prototype.
>


And to get rich off of selling failure. Few of us have that option.

John

Know the design priorities. This means understanding the most critical
requirements.

Understand that all designs are trade-offs between conflicting
requirements and all but one solution are sub-optimal given the
solution space. No matter what design technique you use, including all
diagramming and emergent design processes, this is true. You are not
likely to find the optimal solution.

Depending on the end purpose, and if it truly is highly complex,
multiple design teams are a good idea. They'll have landed upon
differing sub-optimal solutions. Comparing and reconciling the
competing designs can lead to a better sub-optimal solution.

Make sure you fully understand the problem. Break down the problem into
sub problems. This is easiest for me to do in a hierarchical fashion,
but is not the only way. There are many good, non-software engineering
books that talk about problems solving and present diagraming
techniques. If you are serious about design, you should read a few of
these and even play with other diagramming techniques (though don't
necessarily try to impose these non-SE diagrams on the corporation!).
The design does not have to be hierachical, and the implementation
probably should not be.

Prototype the difficult problems.

Support the design with tests (test before code!).

Walk through designs. Absolutely!

Know that requirements change.

>... For some
>reason, managers and customers seem to think that software can be
>changed much more easily than mechanical systems... so they do.

Do you think that software is as hard to change as mechanical systems?

or is it possible that, even though software is easier to change than a
mechnical system, it still requires some work and many
managers/customers assume easier change = free change?

"Jerry Avins" <jya@ieee.org> wrote in message 
news:Moqdnb_Afo1SZXnfRVn-2Q@rcn.net...
> Fred Marshall wrote:
>> "Jerry Avins" <jya@ieee.org> wrote in message 
>> news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
>>
>
> "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 

"scottfrye" <scottf3095@aol.com> wrote in message 
news:1122308450.491025.165850@g14g2000cwa.googlegroups.com...
> >... For some
>>reason, managers and customers seem to think that software can be
>>changed much more easily than mechanical systems... so they do.
>
> Do you think that software is as hard to change as mechanical systems?
>
> or is it possible that, even though software is easier to change than a
> mechnical system, it still requires some work and many
> managers/customers assume easier change = free change?
>

I depends.  It's pretty easy to change the diameter of a hole in AutoCAD. 
So, if that's the context of a change to a mechanical system then it's just 
as easy as changing a line of code.  In fact, it's equivalent to changing 
the value of a constant and that's how it's done.  Now, if the next step is 
to reprogram an NC machine, then that's something additional.  But isn't 
that similar to linking the new compiled code...?  Maybe.

Fred 

"Peter K." <p.kootsookos@iolfree.ie> writes:

> Randy Yates wrote:
>
>> 6. Be patient.
>>
>> Waiting for a system to be properly designed will almost always be
>> more efficient (time-wise) than "waterfall development," i.e., the
>> type of development for impatient managers that want to see something
>> almost immediately.
>
> I disagree.  A better model (than either big up-front design or
> waterfall), in software development, is the spiral / agile model of
> development.   I've found this model to be excellent, especially when
> the requirements change or are not fully elicited --- as they usually
> are in the sorts of software I've developed (greenfield ones).

I'm not familiar with the spiral/agile model, but you'll have to
do some pretty fancy talking to convince me to agree that something
other than a strict development cycle flow is going to produce a better
system in the long run. 

The problem I've seen is that, in the process of stumbling over one's
feet to get _something_ out that works, that the managers can
touchie-feelie-see, one ends up skimping or dumbing down the high
level design. Then, when that happens, the remainder of the project's
development is crippled, with the end result either that it took MORE
time than it would have taken had a proper high level design been
performed, or that the performance/maintainability/extendability of
the system is greatly comprimised.

> Big up-front design can be a killer when requirements change.  For some
> reason, managers and customers seem to think that software can be
> changed much more easily than mechanical systems... so they do.  The
> trick is to figure out when they're really expressing a new
> requirement, or just jumping on the latest Big Thing.

You can't have your cake and eat it too. Either take a hit sticking
to your requirements, or dumb-down your system.
-- 
%  Randy Yates                  % "I met someone who looks alot like you,
%% Fuquay-Varina, NC            %             she does the things you do, 
%%% 919-577-9882                %                     but she is an IBM."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Fred Marshall wrote:
> "Jerry Avins" <jya@ieee.org> wrote in message 
> news:Moqdnb_Afo1SZXnfRVn-2Q@rcn.net...
> 
>>Fred Marshall wrote:
>>
>>>"Jerry Avins" <jya@ieee.org> wrote in message 
>>>news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
>>>
>>
>>"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.
�����������������������������������������������������������������������

Randy Yates wrote:

> I'm not familiar with the spiral/agile model, but you'll have to
> do some pretty fancy talking to convince me to agree that something
> other than a strict development cycle flow is going to produce a better
> system in the long run.

Oh, it's still a strict development cycle... if anything, it's more
strict than the big design up front.  It just panders a little better
to customers and, in my experience, handles changing requirements much
better.

> The problem I've seen is that, in the process of stumbling over one's
> feet to get _something_ out that works, that the managers can
> touchie-feelie-see, one ends up skimping or dumbing down the high
> level design.

Not at all.  You don't dumb down the design, you just instantiate those
parts of it that are clearest first.

> Then, when that happens, the remainder of the project's
> development is crippled, with the end result either that it took MORE
> time than it would have taken had a proper high level design been
> performed, or that the performance/maintainability/extendability of
> the system is greatly comprimised.

It depends on what you mean by "proper high level design" --- don't get
me wrong, there is still abstract, forward-leaning thought involved.
It's just that most designs I've seen try to get too stuck into details
too early.

> > Big up-front design can be a killer when requirements change.  For some
> > reason, managers and customers seem to think that software can be
> > changed much more easily than mechanical systems... so they do.  The
> > trick is to figure out when they're really expressing a new
> > requirement, or just jumping on the latest Big Thing.
>
> You can't have your cake and eat it too. Either take a hit sticking
> to your requirements, or dumb-down your system.

Actually, you can.  That's part of the point of the spiral / agile
methods: allow some flux in requirements (it will always be there), but
don't make dumb decisions about it.

Ciao,

Peter K.

"Jerry Avins" <jya@ieee.org> wrote in message 
news:8OOdnYevi6v6_3nfRVn-jw@rcn.net...
> 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

scottfrye wrote:

>>... For some
>>reason, managers and customers seem to think that software can be
>>changed much more easily than mechanical systems... so they do.
>>    
>>
>
>Do you think that software is as hard to change as mechanical systems?
>  
>
Bad experiences in defence systems means some defence customers are 
*much* happier to make large physical changes than small software ones. 
The software change itself can be simple, but testing it for unforseen 
consequences can be a nightmare. Especially if it is safety critical 
(e.g. flight control systems).

>or is it possible that, even though software is easier to change than a
>mechnical system, it still requires some work and many
>managers/customers assume easier change = free change?
>  
>
I think most managers are just in love with the notion they can fix 
things economically after the product has shipped. Viva flash! :-)

Regards,
Steve

Peter K. wrote:

>Randy Yates wrote:
>
>  
>
>>I'm not familiar with the spiral/agile model, but you'll have to
>>do some pretty fancy talking to convince me to agree that something
>>other than a strict development cycle flow is going to produce a better
>>system in the long run.
>>    
>>
>
>Oh, it's still a strict development cycle... if anything, it's more
>strict than the big design up front.  It just panders a little better
>to customers and, in my experience, handles changing requirements much
>better.
>
>  
>
>>The problem I've seen is that, in the process of stumbling over one's
>>feet to get _something_ out that works, that the managers can
>>touchie-feelie-see, one ends up skimping or dumbing down the high
>>level design.
>>    
>>
>
>Not at all.  You don't dumb down the design, you just instantiate those
>parts of it that are clearest first.
>
>  
>
>>Then, when that happens, the remainder of the project's
>>development is crippled, with the end result either that it took MORE
>>time than it would have taken had a proper high level design been
>>performed, or that the performance/maintainability/extendability of
>>the system is greatly comprimised.
>>    
>>
>
>It depends on what you mean by "proper high level design" --- don't get
>me wrong, there is still abstract, forward-leaning thought involved.
>It's just that most designs I've seen try to get too stuck into details
>too early.
>
>  
>
>>>Big up-front design can be a killer when requirements change.  For some
>>>reason, managers and customers seem to think that software can be
>>>changed much more easily than mechanical systems... so they do.  The
>>>trick is to figure out when they're really expressing a new
>>>requirement, or just jumping on the latest Big Thing.
>>>      
>>>
>>You can't have your cake and eat it too. Either take a hit sticking
>>to your requirements, or dumb-down your system.
>>    
>>
>
>Actually, you can.  That's part of the point of the spiral / agile
>methods: allow some flux in requirements (it will always be there), but
>don't make dumb decisions about it.
>  
>
The key problem with anything that produces an early prototype is 
managers tend to mistake the prototype for something near to market 
ready, however emphatically they are told it isn't. Without the pressure 
that brings I doubt people like Randy would be criticising more adaptive 
methodologies.

My experience with completely up front designs is they always produce 
something obsolete by its shipping date. I think anything more adaptive 
than that has to be of huge benefit, whatever drawbacks it has.

Regards,
Steve

"Jerry Avins" <jya@ieee.org> wrote in message 
news:8OOdnYevi6v6_3nfRVn-jw@rcn.net...
> Matt Timmermans wrote:
>
> 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.

In my experience, those who are tasked with writing detailed software 
specifications (e.g. sales and marketing) are often not qualified to do so.  It 
seems that the ability to write a very precise and detailed specification is a 
very similar skill set to the ability to write the software itself!  So unless 
the spec writer is a programmer himself, it is usually severely lacking in 
detail and precision, at least in my experience.  Your story (snipped) 
illustrates that concept nicely. 

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message 
news:1122287353.66c85a156040e266c1dce57215063b78@teranews...
> On a sunny day (Mon, 25 Jul 2005 10:23:45 +0800) it happened Steve Underwood
> <steveu@dis.org> wrote in <dc1ifi$cs2$1@home.itg.ti.com>:
>
>>Oh what bliss. A man who's free of inner conflicts. I often vigorously
>>disagree with myself - especially when my tongue is saying "eat that"
>>while my brain is saying "now, just how many kilos did the bathroom
>>scales show the other day?" :-)
>>
>>As America's great philsopher G.W. Bush so wisely said "I have opinions
> You mean THIS philosopher:
> ftp://panteltje.com/Bush_a_man_without_vision.jpg

FYI, that photo is debunked here:
http://www.snopes.com/photos/binoculars.asp 

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message 
news:roCdnQY0lNkxynjfRVn-uA@centurytel.net...
>
> "scottfrye" <scottf3095@aol.com> wrote in message 
> news:1122308450.491025.165850@g14g2000cwa.googlegroups.com...
>> >... For some
>>>reason, managers and customers seem to think that software can be
>>>changed much more easily than mechanical systems... so they do.
>>
>> Do you think that software is as hard to change as mechanical systems?
>>
>> or is it possible that, even though software is easier to change than a
>> mechnical system, it still requires some work and many
>> managers/customers assume easier change = free change?
>>
>
> I depends.  It's pretty easy to change the diameter of a hole in AutoCAD. So, 
> if that's the context of a change to a mechanical system then it's just as 
> easy as changing a line of code.  In fact, it's equivalent to changing the 
> value of a constant and that's how it's done.  Now, if the next step is to 
> reprogram an NC machine, then that's something additional.  But isn't that 
> similar to linking the new compiled code...?  Maybe.

At least in my company, after you change the diameter of the hold in AutoCAD, 
you have to update required documentation, notify the vendor, possibly pay a 
change fee, figure out how to deal with the existing units with the "wrong" 
whole size (see through, throw away, return for correction), verify the fix has 
been implemented, etc..  The software is more like change the code, test it, and 
post it on the web site.  It still takes work, but it's all in house, requires 
less time and management, and usually less cost.  But for a manufacturing 
company that out-sourced its software, it could be the opposite! 

Jerry Avins wrote:

Stung by the spell checker!

> document. I excepted as a requirements specification a users manual that 

I accepted as a requirements ...

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

Jon Harris wrote:
> "Jerry Avins" <jya@ieee.org> wrote in message 
> news:8OOdnYevi6v6_3nfRVn-jw@rcn.net...
> 
>>Matt Timmermans wrote:
>>
>>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.
> 
> 
> In my experience, those who are tasked with writing detailed software 
> specifications (e.g. sales and marketing) are often not qualified to do so.  It 
> seems that the ability to write a very precise and detailed specification is a 
> very similar skill set to the ability to write the software itself!  So unless 
> the spec writer is a programmer himself, it is usually severely lacking in 
> detail and precision, at least in my experience.  Your story (snipped) 
> illustrates that concept nicely. 

Sort of. If you want to sell what I write, don't tell me what it should 
do. Describe to your prospective customer what it will do, and show me.

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

Steve Underwood wrote:

> The key problem with anything that produces an early prototype is
> managers tend to mistake the prototype for something near to market
> ready, however emphatically they are told it isn't. Without the pressure
> that brings I doubt people like Randy would be criticising more adaptive
> methodologies.

I agree that this is an issue.  It's a matter of "training" your
stakeholders, though, and I've had more success with incremental
involvement of stakeholders (in parallel with the incremental
implementation), than trying to get their whole-hearted attention for
the times when a big design needs it.

The phrase "attention span of a gnat" springs to mind.

> My experience with completely up front designs is they always produce
> something obsolete by its shipping date. I think anything more adaptive
> than that has to be of huge benefit, whatever drawbacks it has.

There are certainly benefits and costs to all approaches.  As previous
posters have said, you need to choose the approach that satisfies as
many of the interested parties as possible.  The more you know about
each approach, the better you can pick the right(est) one.

Ciao,

Peter K.

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

Ah, at last somebody who is capable of putting into words what I think!

The reason why I got concerned about these things (apart from having
learned x86 assembly under that ridiculous MS-DOS memory model with
64k segments and the memory beyond 1M all but unreachable) was a
code for scientific computations I used during my MSc project.

The MSC project, where I tested a method to do a certain type of
data analysis, evolved into a code-development project for a company
whose data I had used for testing. These people wanted to use my
techniques in their R&D facility. They wanted to see if they could
use the technique in their in-house data processing.

The brief for the post-MSc project was reasonable: Take the ecclectic
program system, consisting of fortran, C and matlab code snippets, and
convert into a C demo program that could be used as a stand-alone
application by the staff.

Everybody understood that it was out of the question to re-implement
the core scientific routine that was available in fortran.

I did everyting else: Wrote the main wrap-around, the data-I/O,
implemented the tricks I had come up with in the MSc project. All that
remained was to make a GUI for some interactive handling of the data,
and to marry the fortran code to the rest of the program. The GUI had
to wait for now, it could be handled by other means. The important
thing was to include the core fortran program, so the main
fucntionality
was available.

The fortran program originated as some "example code" for a textbook
on numerical modelling, that appeared around 1978-79. The five-page
overview of the particular modeling technique, as found in that book,
was the only "documentation" available for the code. The book gave
an overview of the theory. It was of no use whatsoever, what the code
was concerned.

The program itself was straight-forward. There was a main function
that imported some parameters, organized some loops, and passed
the parameters to the core subfunctions. The parameter IO in the
main program was by file. Not that it mattered, I could write a
wrap-around function in C and call the fortran core subfunctions
from there.

Except it was not possible. Every status or error message generated
by the core subfunctions were written to file, not passed back to the
main function. Every computed parameter was written to file, not passed
back. The concept of "returning the results in arrays for the main
program to decide what to do" had not been respected. There was no way
of implementing a smilar code from scratch; doing that is a project at
the PhD level. (I know people who got their PhD degrees by writing
codes
with exactly the same functionally, if not in the same way.) There
was no way of re-structuring the existing code, since no relevant
documentation existed.

So the project blew sky high, if compared to the original brief.
I was less than happy about that, but "luckily", the people involved
decided it could continue as an R&D project, and so I got onto the
path towards my PhD.

Since then, I have been very aware about documentation, error
handling, data structures, data flows etc. What I call "design".

Rune

"Fred Marshall" wrote....
>"scottfrye" <scottf3095@aol.com> wrote in message
>news:1122308450.491025.165850@g14g2000cwa.googlegroups.com...
>> >... For some
>>>reason, managers and customers seem to think that software can be
>>>changed much more easily than mechanical systems... so they do.
>>
>> Do you think that software is as hard to change as mechanical systems?
>>
>> or is it possible that, even though software is easier to change than a
>> mechnical system, it still requires some work and many
>> managers/customers assume easier change = free change?
>>

>I depends.  It's pretty easy to change the diameter of a hole in AutoCAD.
>So, if that's the context of a change to a mechanical system then it's just
>as easy as changing a line of code.  In fact, it's equivalent to changing
>the value of a constant and that's how it's done.  Now, if the next step is
>to reprogram an NC machine, then that's something additional.  But isn't
>that similar to linking the new compiled code...?  Maybe.
>
>Fred

However, when you change the diameter of a hole in AutoCAD you then
have to go
thru the physical process of actually changing the hole diameter it the
end
part.  With software, once the line of code is changed, you recompile
and the
change is done (minus any paperwork and distribution).

- Scott Frye

Jerry Avins wrote:
> 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.

Same as me, then. That's why I am so obstinate about "design", about
getting it right. If not "first time", so "some time". "Early" would
be preferable.

> 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.*

Sure. The problem is, as you indicate, when one does not discriminate
between an initial prototype and the finished product.

> 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.

Must of the bugs I've found, were typos or other blunders that made
me look plain stupid. There were one or two, though, I learned a lot
from. Here is one that took me a month to find. I only
understood there was a problem after I ported the code from one
system to another.

/** C code *************************************************/

float a;
float *p;
int i;

/* initialize p as an array containing N > i floats */

a =3D *p[i];

/***********************************************************/

> 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.

Now we are talking. "Making it part of the planning process."

> 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.

Or it might screw the whole thing up, what subsequent extensions
are concerned.

Rune

> 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.
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

It seems to me that much of this discussion is tempered by the size of 
the organization that each participant is involved in.

For virtually all my career, I have worked (and had ownership in) small 
companies. I think this case, the marketing & engineering aspects of the 
projects tend to be more naturally coupled together and management is not 
likely to be pointy haired.

In most of my larger projects (which for me might involve 4-5 people), we 
usually had a fairly good vision of what we wanted to accomplish when we 
started, but at the same time, we never over specified a project from the 
start.

Nevertheless, we rarely built lots of small incremental prototypes, it 
takes too long. We used kind of a successive approximation method that 
was drove to the production version as soon as possible. Sure, we might 
have prototyped small segments as needed. In most projects, the 
collective talent already knows how to do 80 - 90% of the project before 
it even starts (or knows where the answers lie). Dotting every i and 
crossing every t, is very slow. You also tend to create a number of very 
good useless pieces that you discard anyway. If the project takes too 
long, the solution may no longer be relevant.  

I think the key to the successful projects, that I worked on was that 
everyone understood the basic vision, and there was always a architect on 
the project that understood the broader issues. You can always find a 
better way of solving a problem the next time. Sometimes, its because you 
learned something from the previous project, sometimes its new components 
(like a new DSP chip), sometimes its economics, etc. One of the 
challenges for the project leader (who in our case was usually the 
architect), was to access when to change course in the middle of a 
project and when to stay the course (and sometimes shoot the engineers).

I have killed projects in the middle and almost completely started over. 
This is painful, but usually, the next attempt is a lot better.

Probably, the most successful project I was involved in started with a 
well defined goal, that had 2.5 months to bring from idea to production 
(including deliverable products). The timing was forced by a trade show. 

We designed everything as a production solution (extruded housings, 
injection molded bezels, custom circuit boards, firmware, etc). We didn't 
even start the firmware until the last week before the tradeshow. This 
was actually part of the plan since timing was everything. The team 
consisted of 5 people. 

Suffice to say, we were the most successful exhibitor at the tradeshow. 
We had people standing three deep into the exhibit floor most of the 
show. After about a year, we had captured about 80% of our market (we had 
two competitors when we launched our product at the tradeshow). 

If we had followed the build a little, test, build a little more, we 
would not have succeeded since time to market would have let the 
opportunity slip away.



-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com





"Peter K." <p.kootsookos@iolfree.ie> wrote in
news:1122341607.028547.67040@g49g2000cwa.googlegroups.com: 

> Randy Yates wrote:
> 
>> I'm not familiar with the spiral/agile model, but you'll have to
>> do some pretty fancy talking to convince me to agree that something
>> other than a strict development cycle flow is going to produce a
>> better system in the long run.
> 
> Oh, it's still a strict development cycle... if anything, it's more
> strict than the big design up front.  It just panders a little better
> to customers and, in my experience, handles changing requirements much
> better.
> 
>> The problem I've seen is that, in the process of stumbling over one's
>> feet to get _something_ out that works, that the managers can
>> touchie-feelie-see, one ends up skimping or dumbing down the high
>> level design.
> 
> Not at all.  You don't dumb down the design, you just instantiate
> those parts of it that are clearest first.
> 
>> Then, when that happens, the remainder of the project's
>> development is crippled, with the end result either that it took MORE
>> time than it would have taken had a proper high level design been
>> performed, or that the performance/maintainability/extendability of
>> the system is greatly comprimised.
> 
> It depends on what you mean by "proper high level design" --- don't
> get me wrong, there is still abstract, forward-leaning thought
> involved. It's just that most designs I've seen try to get too stuck
> into details too early.
> 
>> > Big up-front design can be a killer when requirements change.  For
>> > some reason, managers and customers seem to think that software can
>> > be changed much more easily than mechanical systems... so they do. 
>> > The trick is to figure out when they're really expressing a new
>> > requirement, or just jumping on the latest Big Thing.
>>
>> You can't have your cake and eat it too. Either take a hit sticking
>> to your requirements, or dumb-down your system.
> 
> Actually, you can.  That's part of the point of the spiral / agile
> methods: allow some flux in requirements (it will always be there),
> but don't make dumb decisions about it.
> 
> Ciao,
> 
> Peter K.
> 

Hello everyone, I am floored by the number of responses to my original
post. I want to thank everyone for taking the time to express their
thoughts, experiences and opinions. I also want to pass on a document I
found on the internet,
http://www.guymacon.com/ENGINEER/PLANNING/INDEX.HTM

If you have some free time check it out.

Again, I want to thank everyone for sharing their opinions.

joe

jjlindula@hotmail.com wrote:
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks? It may sound like a weird question, but there
> must be some guidelines, best practices, or habits used to achieve
> success in designing/developing a complex project. I'm sure there must
> be some individuals out there that are constantly taking complex tasks
> and just about every time have success with it. Short of speaking, I
> want to know what's the secret to their success. All comments are
> welcomed, even the most obvious suggestions.
>
> As an engineer, I'm constantly trying to improve my design processes.
> 
> Thanks everyone,
> joe

Steve Underwood <steveu@dis.org> writes:
> [...]
> My experience with completely up front designs is they always produce
> something obsolete by its shipping date. I think anything more
> adaptive than that has to be of huge benefit, whatever drawbacks it
> has.

I'll see you and Peter in the marketplace.
-- 
%  Randy Yates                  % "Ticket to the moon, flight leaves here today 
%% Fuquay-Varina, NC            %  from Satellite 2"
%%% 919-577-9882                % 'Ticket To The Moon' 
%%%% <yates@ieee.org>           % *Time*, Electric Light Orchestra
http://home.earthlink.net/~yatescr

Randy Yates <yates@ieee.org> wrote in news:3bq1jcy4.fsf@ieee.org:

> Steve Underwood <steveu@dis.org> writes:
>> [...]
>> My experience with completely up front designs is they always produce
>> something obsolete by its shipping date. I think anything more
>> adaptive than that has to be of huge benefit, whatever drawbacks it
>> has.
> 

This is my view as well.


> I'll see you and Peter in the marketplace.


I love that last line. 



-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

"Al Clark" <dsp@danvillesignal.com> wrote in message 
news:Xns969FCA9BA4900aclarkdanvillesignal@66.133.129.71...
> Randy Yates <yates@ieee.org> wrote in news:3bq1jcy4.fsf@ieee.org:
>
>> Steve Underwood <steveu@dis.org> writes:
>>> [...]
>>> My experience with completely up front designs is they always produce
>>> something obsolete by its shipping date. I think anything more
>>> adaptive than that has to be of huge benefit, whatever drawbacks it
>>> has.
>>
>
> This is my view as well.
>
>
>> I'll see you and Peter in the marketplace.
>
>
> I love that last line.
>

Me too Al.  An awful lot has to do with product cycle time.

I worked at a place where the cycle time was quite short.  There was lots of 
re-use of "infrastructure parts".  So, the idea of making many changes after 
the initial design was pretty remote.  There wasn't time if we were going to 
get to market.  The products weren't obsolete with a cycle time that could 
be under 1 year.  We also relied on field programmable FPGA designs.  So, 
changes weren't out of the question but were "soft" in that sense and didn't 
necessarily count in the "few changes" sense of things.

Fred 

Peter K. wrote:
> Steve Underwood wrote:
>
> > The key problem with anything that produces an early prototype is
> > managers tend to mistake the prototype for something near to market
> > ready, however emphatically they are told it isn't. Without the pressure
> > that brings I doubt people like Randy would be criticising more adaptive
> > methodologies.
>
> I agree that this is an issue.

Well, I did see -- from a safe distance, thankfully -- a software
project in progress, that did "produce results" extremely quickly.
Somebody was making some sort of data processing tool. The department
(perhaps even the people) involved in this particular project, had at
a previous time been involved in developing a production analysis tool
of similar nature.

What had happened in the mean time, was that both matlab and IDL had
provided GUI development tools as part of the programming system.

So these guys were capable of producing a GUI where the data was
visualized, manipulated and handled, along with some simple IO etc,
in a matter of hours. Previously, they had used weeks or months
for design, analysis etc, before starting coding, let alone have
a demo ready to show.

People were flabbergasted by the "results". The nice, fancy images
on the screen. "This proves that those guys from the other department,
who ran the previous project and insisted on all that bueracracy,
had no idea whatsoever what they wre doing."

Sure, the demo was impressive enough. But could it handle production-
type data sets, that could be tens of gigabytes? I don't know.
Could it be maintained in a decent way? I don't know. Could it be
extended with further functions? I don't know. Could the GUI be
changed easily, if the intended users had remarks on the operation?
I don't know. Could it be modified to accomodate slightly different
analysis tasks? I don't know.

In this case, the demo was percieved as "a product", right here
and then. No one who asked for time or resources to "get it right"
would get anything; there was no need for it. The program was
already there, running, "working".

And the serious long-term effect (which I got to know first-hand)
was that there was no need to allocate neither time nor other
resources in future programming projects: These guys had produced
"a product" in a matter of hours, using the site lisence of either
matlab or IDL. Everybody else was expected to do the same.

All my efforts to get the department to make decisions on data
formats, analysis tools, establish procedures for QC, data validation,
storage formats, reporting standards etc (I thought that getting/making

a software tool for these kinds of jobs might force people to make
decisions of this nature) were met with "It generates too much
bueracracy, people do what they want anyway, and it takes no time to
make a system for the scarcely few instances it might be useful."

> It's a matter of "training" your
> stakeholders, though, and I've had more success with incremental
> involvement of stakeholders (in parallel with the incremental
> implementation), than trying to get their whole-hearted attention for
> the times when a big design needs it.

Sure, that's the only way to train people. Still, I have yet to meet
somebody who don't have hands-on experience with coding and
implementations, who do understand the difference between "demo GUI"
and "product", to paraphrase the example above.

> The phrase "attention span of a gnat" springs to mind.

I don't think it is the full explanation. Lack of hands-on experience
with system analysis and programming, is more likely.

Rune

Jon Harris wrote:
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
> news:roCdnQY0lNkxynjfRVn-uA@centurytel.net...
> >
> > "scottfrye" <scottf3095@aol.com> wrote in message
> > news:1122308450.491025.165850@g14g2000cwa.googlegroups.com...
> >> >... For some
> >>>reason, managers and customers seem to think that software can be
> >>>changed much more easily than mechanical systems... so they do.
> >>
> >> Do you think that software is as hard to change as mechanical systems?
> >>
> >> or is it possible that, even though software is easier to change than a
> >> mechnical system, it still requires some work and many
> >> managers/customers assume easier change = free change?
> >>
> >
> > I depends.  It's pretty easy to change the diameter of a hole in AutoCAD. So,
> > if that's the context of a change to a mechanical system then it's just as
> > easy as changing a line of code.  In fact, it's equivalent to changing the
> > value of a constant and that's how it's done.  Now, if the next step is to
> > reprogram an NC machine, then that's something additional.  But isn't that
> > similar to linking the new compiled code...?  Maybe.
>
> At least in my company, after you change the diameter of the hold in AutoCAD,
> you have to update required documentation, notify the vendor, possibly pay a
> change fee, figure out how to deal with the existing units with the "wrong"
> whole size (see through, throw away, return for correction), verify the fix has
> been implemented, etc..  The software is more like change the code, test it, and
> post it on the web site.  It still takes work, but it's all in house, requires
> less time and management, and usually less cost.  But for a manufacturing
> company that out-sourced its software, it could be the opposite!

Making the change can be as easy as yawning, and still be a nightmare.

We had just bought some new data acquisition system, and was preparing
to
take it to sea for the first time. The system both controlled the ADC
and
stored the data to files, and it was up to us to sort the files out,
rename
and archive them according to the project, survey, run, etc. The system
was,
as far as I know, one of the first of this make and model to be sold.
I would expect the supplier to be interested in getting customer
feedback,
and make those small changes the users would like, to make it easier to

operate.

So the engineer in my department who was responsible for the kit, came
up
with the very sensible idea that the raw data files as generated by the

acquisition system, should be named according to the time they were
started.
The files would get a name as a numerical value according to

   filename = YearMonthDayHourMin

which would yield a unique file name for each file. All we had to do,
then,
was to make a script that compared the file name to the survey log we
anyway would have to write elsewhere. Whoever wanted to use the data
files after the survey, would have to relate to the survey log anyway.

The supplier of the system had no objections to doing the change, but
our engineer had not been very precise in writing the requirements.
She had indicated the change much like I did above, but when we tested
the code (at sea, on our way out to the first survey this piece of kit
would be used...) we got a result like

  Year:  2006
  Month:  7
  Day:    7
  Hour:  14
  Min:   42

  filename = 2006771442.data

The problem? No leading zeros to identify single-digit months, days,
hours
or minutes, making the file name ambiguous with respect to when it was
generated. For instance, was the file

 2006112130.data

generated at 2006 January 12th 0130 hours,  2006 January 1st 2130
hours,
or 2006 November 2nd, 0130 hours? There is no way of telling, unless
the
time stamps in the file systems are preserved, which they are not
guaranteed to be.

The required spec ought to have been

  filename = yyyymmddhhMM

As far as I am concerned, getting it right once the error was
discovered
ought not to take more than 2 minutes. For some reason, the second
request
did throw a serious spanner in the works, what the relationship to the
supplier was concerned. I have no idea why, although it might be that
a controversy over some adjustable gain settings had something to do
with it. I frequently changed the gain settings of the ADC during the
survey, to make up for the somewhat limited dynamics of the fixed-point

ADC. For some reason, the gain settings were never stored in the data
files, so I could not use the data files for my purposes when we got
back to the lab.

I don't know if the time-coded file names ever were generated
correctly.

Rune

Randy Yates wrote:

>
> I'll see you and Peter in the marketplace.
> 

Is that a threat or a promise?  Or both?

:-)

Ciao,

Peter K.

Rune Allnor wrote:

> Well, I did see -- from a safe distance, thankfully -- a software
> project in progress, that did "produce results" extremely quickly.

[SNIP]

> All my efforts to get the department to make decisions on data
> formats, analysis tools, establish procedures for QC, data validation,
> storage formats, reporting standards etc (I thought that getting/making
> a software tool for these kinds of jobs might force people to make
> decisions of this nature) were met with "It generates too much
> bueracracy, people do what they want anyway, and it takes no time to
> make a system for the scarcely few instances it might be useful."

If it could be truly demonstrated that, for this particular company,
that approach worked... why not?

It certainly sounds like a pretty retrograde step they way you describe
it, but if the company could survive by doing things that way (even if
it goes against all the good ISO-9001:2000 / CMMI stuff), then it might
be a valid way to go.

I certainly have come across people who insist on taking an hour to do
something... and every time they do it it takes them an hour.  Whereas
the I try to figure out how to automate it so that, the first time, it
might take me an hour and a half... but the second time takes my 20
minutes, and subsequent times 5 minutes.  The people who don't do the
hard hour every time don't appear to understand the tools at their
disposal, or can't systematize their thinking about the problem enough
to use them effectively.


> > It's a matter of "training" your
> > stakeholders, though, and I've had more success with incremental
> > involvement of stakeholders (in parallel with the incremental
> > implementation), than trying to get their whole-hearted attention for
> > the times when a big design needs it.
>
> Sure, that's the only way to train people. Still, I have yet to meet
> somebody who don't have hands-on experience with coding and
> implementations, who do understand the difference between "demo GUI"
> and "product", to paraphrase the example above.

Maybe.  I've been fortunate enough to be able to convince my higher-ups
to go along to some of the technology training courses so they
understand (at a high level) what we're trying to do and how we're
trying to do it.

> > The phrase "attention span of a gnat" springs to mind.
>
> I don't think it is the full explanation. Lack of hands-on experience
> with system analysis and programming, is more likely.

And them not taking the time to get that experience is, IMHO,
indicative of the attention span of a gnat.

Ciao,

Peter K.

Peter K. wrote:
> Rune Allnor wrote:
>
> > Well, I did see -- from a safe distance, thankfully -- a software
> > project in progress, that did "produce results" extremely quickly.
>
> [SNIP]
>
> > All my efforts to get the department to make decisions on data
> > formats, analysis tools, establish procedures for QC, data validation,
> > storage formats, reporting standards etc (I thought that getting/making
> > a software tool for these kinds of jobs might force people to make
> > decisions of this nature) were met with "It generates too much
> > bueracracy, people do what they want anyway, and it takes no time to
> > make a system for the scarcely few instances it might be useful."
>
> If it could be truly demonstrated that, for this particular company,
> that approach worked... why not?

It's about proepr use of manpower. Manually, the post-experiment
data organization work takes 3-6 months, prior to any analysis.
Most of it is drudgery. Automize that to take, say, 1 - 2 weeks,
and the crew is free to do interesting or even useful stuff.
And you can cut project time and cost with ridiculous amounts.

> It certainly sounds like a pretty retrograde step they way you describe
> it, but if the company could survive by doing things that way (even if
> it goes against all the good ISO-9001:2000 / CMMI stuff), then it might
> be a valid way to go.

Some see the ISO 900x stuff as added bueracracy. It may well be,
but it might also be a very powerful tool to streamline the
production, if used wisely.

In all the marine surveys I know of, either I have taken part myself,
used the data or seen my colleagues be involved in, there have been
ridiculous amounts of drudgery involved. I have seen -- not been
involved in, personally, though -- surveys where it took 4-6 weeks
from the guys came back to the lab to they could start working
with the data. In the mean time they did QC, archiving, adding
geometry, re-formatting,... you name it.

People get unbelievably bored by doing this kind of work in the
first place. Even more so, by doing it for so long time. When
people are bored, they get sloppy. They make mistakes. There is
no need to blame anyone for that, it's merely human nature.

But we need the data, and we don't want all those inevitable
mistakes, due to boredom, to invalidate the data. Experiments
are expensive. Some times even useful.

So the way to do this, is to formalize and automize as much
of the process as possible. If you make a software system
for format control, and make a sensible user interface,
the crew can start the re-formatting job while in transit
back from the survey site. After weeks at sea, they will most
likely be in "zombie mode", but the are still capable of clikcking
boxes in a GUI and filling in descriptions in a dialogue box, as
required. A data validation system that take scarce pieces of
information and stores it in reports, will save incredible amounts
of time, not to mention if some reorganization of data files
can be done as well.

I wouldn't let anyone who have been to sea for any amount of time,
near such a task for at least a month after the return, if it must
be done manually. After a month, people will not be motivated
to get back to work on the data, and we are back to the circle of
boredom - demotivation - sloppyness - errors.

So jumping on the ISO 900x frenzie provides managment with a nice
diploma to hang on the wall, and the crew with an excuse to think
their activities through. Not to mention that the ISO 900x
certifcate is a compulsary requirement prior to getting certain
types of projects.

> I certainly have come across people who insist on taking an hour to do
> something... and every time they do it it takes them an hour.  Whereas
> the I try to figure out how to automate it so that, the first time, it
> might take me an hour and a half... but the second time takes my 20
> minutes, and subsequent times 5 minutes.  The people who don't do the
> hard hour every time don't appear to understand the tools at their
> disposal, or can't systematize their thinking about the problem enough
> to use them effectively.

Well, it's a waste of my time if I have to wait for hours or weeks
for them to provide me with the data I want and need.

Rune

Rune Allnor wrote:

> > If it could be truly demonstrated that, for this particular company,
> > that approach worked... why not?
>
> It's about proepr use of manpower. Manually, the post-experiment
> data organization work takes 3-6 months, prior to any analysis.
> Most of it is drudgery. Automize that to take, say, 1 - 2 weeks,
> and the crew is free to do interesting or even useful stuff.
> And you can cut project time and cost with ridiculous amounts.

Definitely!

Show management the $ different between 3-6 months and 1-2 weeks, and
you'll have your case sown up (they'll be begging you to do it!).

> Some see the ISO 900x stuff as added bueracracy. It may well be,
> but it might also be a very powerful tool to streamline the
> production, if used wisely.

I was involved in a small company that needed ISO9001-2000
accreditation to be considered as a supplier for a major company.  The
company was a start-up and we had complete freedom (within the
constraints of ISO9001) to write our own procedures.

What we did was to figure out what we were doing (and why we were doing
it), look at some "best practices" to see if we should be doing
anything else, and wrote that down as our quality manual.

Because we had the luxury of defining it ourselves, and because we
involved as many people as possible in the discussion about it, we had
really good buy-in and understanding of why the process was necessary.

Heck, we even passed ISO accredition first time with only the minimum
allowable set of data (I think it was 3 months).

My biggest reason for getting the system in place was for clarity of
communicaiton: among team members, between teams, between team leaders
and upper management, between our company and suppliers, between our
company and customers.  

Ciao,

Peter K.

Peter K. wrote:
> Rune Allnor wrote:
>
> > > If it could be truly demonstrated that, for this particular company,
> > > that approach worked... why not?
> >
> > It's about proepr use of manpower. Manually, the post-experiment
> > data organization work takes 3-6 months, prior to any analysis.
> > Most of it is drudgery. Automize that to take, say, 1 - 2 weeks,
> > and the crew is free to do interesting or even useful stuff.
> > And you can cut project time and cost with ridiculous amounts.
>
> Definitely!
>
> Show management the $ different between 3-6 months and 1-2 weeks, and
> you'll have your case sown up (they'll be begging you to do it!).
>
> > Some see the ISO 900x stuff as added bueracracy. It may well be,
> > but it might also be a very powerful tool to streamline the
> > production, if used wisely.
>
> I was involved in a small company that needed ISO9001-2000
> accreditation to be considered as a supplier for a major company.  The
> company was a start-up and we had complete freedom (within the
> constraints of ISO9001) to write our own procedures.
>
> What we did was to figure out what we were doing (and why we were doing
> it), look at some "best practices" to see if we should be doing
> anything else, and wrote that down as our quality manual.
>
> Because we had the luxury of defining it ourselves, and because we
> involved as many people as possible in the discussion about it, we had
> really good buy-in and understanding of why the process was necessary.
>
> Heck, we even passed ISO accredition first time with only the minimum
> allowable set of data (I think it was 3 months).

Brilliant.

> My biggest reason for getting the system in place was for clarity of
> communicaiton: among team members, between teams, between team leaders
> and upper management, between our company and suppliers, between our
> company and customers.

Yeah, those are the exact reasons why I am positive to ISO 900x. 

Rune

"Peter K." <p.kootsookos@iolfree.ie> writes:

> Randy Yates wrote:
>
>>
>> I'll see you and Peter in the marketplace.
>> 
>
> Is that a threat or a promise?  Or both?
>
> :-)

It's a fact.
-- 
%  Randy Yates                  % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC            %                    and kiss her interface, 
%%% 919-577-9882                %            til then, I'll leave her alone."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Randy Yates wrote:
>
> It's a fact.
>

I doubt it!  Our marketplaces (or those of the companies we work for)
are quite different...

Ciao,

Peter K.

"Peter K." <p.kootsookos@iolfree.ie> writes:

> Randy Yates wrote:
>>
>> It's a fact.
>>
>
> I doubt it!  Our marketplaces (or those of the companies we work for)
> are quite different...

If you still think I work for Sony Ericsson, you'd be wrong.
-- 
%  Randy Yates                  % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC            %  you still wander the fields of your
%%% 919-577-9882                %  sorrow."
%%%% <yates@ieee.org>           % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

> 4. Design from the top down. That is, begin the design decomposition
> at the top level and then iteratively break the higher level blocks
> into lower level blocks. AKA hierarchical design.

....

> 5. Implement from the bottom up.

Why implement from the bottom up?

-scott frye

The document has some good infomation, many of my mature customers tell
me exactly what documentation I need to produce so I really have no
choice in the matter!

One comment I thought strange in the document was

"I have worked for Parker Hannifin, an aerospace company where mistakes
result in people being killed. I have worked for Mattel, where the only
factors that matter are how soon you can get the toy into mass
production and how far down you can get the per-toy costs. "

I am sure Mattel has killed more people then any aerospace company due
to its engineering mistakes. (small parts choking kids, electrical toys
starting fires, sharp parts cutting, wires choking, lead poisoning etc
etc).

Randy Yates wrote:

>
> If you still think I work for Sony Ericsson, you'd be wrong.
>

Ah.  That could mean a change, then!  So what is it? Jet engines?
Elevators? Air conditioners? Helicopters? Electronic security? Space
suits? Fuel cells?

> http://home.earthlink.net/~yatescr

You haven't updated this! :0)

Ciao,

Peter K.

scottf3095@aol.com writes:

>> 4. Design from the top down. That is, begin the design decomposition
>> at the top level and then iteratively break the higher level blocks
>> into lower level blocks. AKA hierarchical design.
>
> ...
>
>> 5. Implement from the bottom up.
>
> Why implement from the bottom up?

Because part of the implementation usually includes "unit" testing, or
testing of the pieces, and you must begin such testing with the
smallest pieces possible. Then, when the "foundation" is implemented,
you can begin assembling the foundational pieces into small
subsystems, test those, then piece those together, test those, etc.,
until you have the entire system.
-- 
%  Randy Yates                  % "She's sweet on Wagner-I think she'd die for Beethoven.
%% Fuquay-Varina, NC            %  She love the way Puccini lays down a tune, and
%%% 919-577-9882                %  Verdi's always creepin' from her room." 
%%%% <yates@ieee.org>           % "Rockaria", *A New World Record*, ELO   
http://home.earthlink.net/~yatescr

Randy Yates wrote:

> Because part of the implementation usually includes "unit" testing, or
> testing of the pieces,

I agree with that.

> and you must begin such testing with the
> smallest pieces possible.

I don't necessarily agree with that (the "must" part).  It depends on
where the complexity / newness / risk is.  If the newness is in the
"glue" binding the smallest peices together, then it's sometimes
possible to emulate/simulate the smallest posces pissible (as typed)
and concentrate on getting the glue right.

> Then, when the "foundation" is implemented,
> you can begin assembling the foundational pieces into small
> subsystems, test those, then piece those together, test those, etc.,
> until you have the entire system.

I think this is just one valid approach (bottom-up implementation).
It's not the only valid one.

Where an existing product-line is being replaced with the newly
designed product, it's possible to use the existing, working product as
"the complete system" and replace components of it as those components
get re-designed and re-implemented.

In software, you can start off implementation at a high-level of
abstraction and just "stub-out" the detail until you're ready to deal
with it.  When I start implementing software, I don't (necessarily)
start implementing a function... I first figure out what modules /
classes / components need to be there  and instantiate them.  Then I
figure out what external interfaces those classes need to present to
each other. Etc. etc.

Ciao,

Peter K.

Peter K. wrote:
> Randy Yates wrote:
> 
> 
>>Because part of the implementation usually includes "unit" testing, or
>>testing of the pieces,
> 
> 
> I agree with that.
> 
> 
>>and you must begin such testing with the
>>smallest pieces possible.
> 
> 
> I don't necessarily agree with that (the "must" part).  It depends on
> where the complexity / newness / risk is.  If the newness is in the
> "glue" binding the smallest peices together, then it's sometimes
> possible to emulate/simulate the smallest posces pissible (as typed)
> and concentrate on getting the glue right.
> 
> 
>>Then, when the "foundation" is implemented,
>>you can begin assembling the foundational pieces into small
>>subsystems, test those, then piece those together, test those, etc.,
>>until you have the entire system.
> 
> 
> I think this is just one valid approach (bottom-up implementation).
> It's not the only valid one.
> 
> Where an existing product-line is being replaced with the newly
> designed product, it's possible to use the existing, working product as
> "the complete system" and replace components of it as those components
> get re-designed and re-implemented.
> 
> In software, you can start off implementation at a high-level of
> abstraction and just "stub-out" the detail until you're ready to deal
> with it.  When I start implementing software, I don't (necessarily)
> start implementing a function... I first figure out what modules /
> classes / components need to be there  and instantiate them.  Then I
> figure out what external interfaces those classes need to present to
> each other. Etc. etc.

Whatever works for you is good. Writing stubs may be worth the effort, 
bur not writing stubs is less effort.

I try to start with interfaces and data structures, and to write small 
testable pieces that instantiate or use them. Every piece incorporated 
into a larger structure has already been vetted, and unless I've made a 
false start, nothing is discarded.

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

"Randy Yates" <yates@ieee.org> wrote in message
news:<d5p1nj1u.fsf@ieee.org>...
> scottf3095@aol.com writes:
>
> >> 4. Design from the top down. That is, begin the design decomposition
> >> at the top level and then iteratively break the higher level blocks
> >> into lower level blocks. AKA hierarchical design.
> >
> > ...
> >
> >> 5. Implement from the bottom up.
> >
> > Why implement from the bottom up?
>
> Because part of the implementation usually includes "unit" testing, or
> testing of the pieces, and you must begin such testing with the
> smallest pieces possible. Then, when the "foundation" is implemented,
> you can begin assembling the foundational pieces into small
> subsystems, test those, then piece those together, test those, etc.,
> until you have the entire system.

Is there any other reason besides "to support unit testing" to
implement from the bottom up?  I was wondering if the people that have
problems with TDD might be the people that are used to implementing
form the top down.

I have always coded from the top down.  I make a user interface, then
start figuring out how what is needed to support the user interface.  I
add stub classes with comments like "UNDONE" or "TODO".  When I can
search my entire project and I don't find any of these comments, then
I'm done.
Of course this method has made adopting TDD very diffucult for me.

Does anyone else prefer top down to bottom up development?  and has
that hindered your adoption of TDD?

"Peter K." <p.kootsookos@iolfree.ie> wrote in message
news:<1122745043.996259.309120@g43g2000cwa.googlegroups.com>...
>
> In software, you can start off implementation at a high-level of
> abstraction and just "stub-out" the detail until you're ready to deal
> with it.  When I start implementing software, I don't (necessarily)
> start implementing a function... I first figure out what modules /
> classes / components need to be there  and instantiate them.  Then I
> figure out what external interfaces those classes need to present to
> each other. Etc. etc.
>

Do you find that this impairs your ability to apply unit tests,
specifically as TDD?

-Scott Frye

scott frye wrote:
> Is there any other reason besides "to support unit testing" to
> implement from the bottom up?  I was wondering if the people that have
> problems with TDD might be the people that are used to implementing
> form the top down.

Yep. Top down design often produces a module split which looks great at 
first sight, but doesn't play out too well in practice. It might be 
clumsy to implement, or it might produce inefficient results. Also top 
down often produces a split which doesn't match well with existing code, 
and inhibits reuse of that code. Implementing bottom up makes you aware 
of these issues at an early stage, while reworking the top down design 
is still a fairly lightweight task.

Regards,
Steve

Steve Underwood wrote:
> scott frye wrote:
> 
>> Is there any other reason besides "to support unit testing" to
>> implement from the bottom up?  I was wondering if the people that have
>> problems with TDD might be the people that are used to implementing
>> form the top down.
> 
> 
> Yep. Top down design often produces a module split which looks great at 
> first sight, but doesn't play out too well in practice. It might be 
> clumsy to implement, or it might produce inefficient results. Also top 
> down often produces a split which doesn't match well with existing code, 
> and inhibits reuse of that code. Implementing bottom up makes you aware 
> of these issues at an early stage, while reworking the top down design 
> is still a fairly lightweight task.

I'd like to illuminate that with an example. One project needed to 
control a bunch of switches, implemented as bit-I/O . The top-down plan 
called for the functions (in C usage) on(), off(), and toggle(). It was 
known at planning time that actual outputs would be word wide. The 
bottom-up design immediately turned up a snag. The I/O device's state 
couldn't be read, so an image of its state would need to be kept in 
memory. With the switch bank serving several tasks, that might have 
necessitated the inclusion of an otherwise unneeded semaphore system. 
Discovering that late in a top-down implementation would have meant a 
lot of code rework. (That's all subjunctive because I built hardware to 
avoid the problem. The freedom to do that isn't always to be had.)

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

On Mon, 1 Aug 2005 12:20:14 UTC, Steve Underwood <steveu@dis.org> wrote:

> scott frye wrote:
> > Is there any other reason besides "to support unit testing" to
> > implement from the bottom up?  I was wondering if the people that have
> > problems with TDD might be the people that are used to implementing
> > form the top down.
> 
> Yep. Top down design often produces a module split which looks great at 
> first sight, but doesn't play out too well in practice. It might be 
> clumsy to implement, or it might produce inefficient results. Also top 
> down often produces a split which doesn't match well with existing code, 
> and inhibits reuse of that code. Implementing bottom up makes you aware 
> of these issues at an early stage, while reworking the top down design 
> is still a fairly lightweight task.
> 
> Regards,
> Steve

  As with most approaches to any problem, the appropriate method should
be used.  Properly mixing the top-down and bottom-up methods to your
needs.  Some problems are best solved by building up a solution, others
by decomposing or structuring the proposed solution, a few rare instances
may even need a middle-out approach if your existing solution base is
the inside (not top or bottom) for the final solution.  Refactoring,
reworking, or whatever is always available to revise an appropriate
solution.  Use the techniques that best fit your needs and design
approach.

  David

Jerry Avins wrote:
> Steve Underwood wrote:
> 
>> scott frye wrote:
>>
>>> Is there any other reason besides "to support unit testing" to
>>> implement from the bottom up?  I was wondering if the people that have
>>> problems with TDD might be the people that are used to implementing
>>> form the top down.
>>
>>
>>
>> Yep. Top down design often produces a module split which looks great 
>> at first sight, but doesn't play out too well in practice. It might be 
>> clumsy to implement, or it might produce inefficient results. Also top 
>> down often produces a split which doesn't match well with existing 
>> code, and inhibits reuse of that code. Implementing bottom up makes 
>> you aware of these issues at an early stage, while reworking the top 
>> down design is still a fairly lightweight task.
> 
> 
> I'd like to illuminate that with an example. One project needed to 
> control a bunch of switches, implemented as bit-I/O . The top-down plan 
> called for the functions (in C usage) on(), off(), and toggle(). It was 
> known at planning time that actual outputs would be word wide. The 
> bottom-up design immediately turned up a snag. The I/O device's state 
> couldn't be read, so an image of its state would need to be kept in 
> memory. With the switch bank serving several tasks, that might have 
> necessitated the inclusion of an otherwise unneeded semaphore system. 
> Discovering that late in a top-down implementation would have meant a 
> lot of code rework. (That's all subjunctive because I built hardware to 
> avoid the problem. The freedom to do that isn't always to be had.)
> 
> Jerry

If you built the hardware to avoid the problem after it was discovered 
then it's evidence to support bottom-up implementation -- because the 
problem would not have been discovered at the bottom of the software to 
be fixed at an even lower level.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com