FPGA Central

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

<[email protected]> wrote in message
news:[email protected] oups.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 [email protected]
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

[email protected] 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

[email protected] 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.

<[email protected]> wrote in message
news:[email protected] oups.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

[email protected] 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" <[email protected]> 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 <[email protected]> wrote in
news:[email protected]:

> On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <[email protected]> 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

[email protected] 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" <[email protected]> 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

[email protected] 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

<[email protected]> wrote in message
news:[email protected] oups.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:

>
> [email protected] 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

<[email protected]> wrote in message
news:[email protected] oups.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:
>
> >
> > [email protected] 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" <[email protected]> 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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Fred Marshall skrev:
> <[email protected]> wrote in message
> news:[email protected] oups.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:
>
>><[email protected]> wrote in message
>>news:[email protected] groups.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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯