Best Practices to Manage Complexity in Hardward/Software Design?

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

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.

My thoughts exactly.

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.

My point exactly.

Rune

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:

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

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

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?

Agreed.

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

Rune

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

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

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

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

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

Steve

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?«

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.

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.

Indeed.

Rune

Erik de Castro Lopo wrote: (snip)

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

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:

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

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.

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

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.

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

Rune

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.

..

...

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

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

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

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.

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