Best Practices to Manage Complexity in Hardward/Software Design?

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" :-)

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.

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.

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

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

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.

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

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

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

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

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

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

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.

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

Joe,

One of the people I respect most in this area is Paul Bennett,

Jerry

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

John

John Larkin wrote in news: snipped-for-privacy@4ax.com:

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.

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.

Col> Hello, I'm interested in how individuals or design groups manage

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

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.

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

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

Google his name and "leaky".

"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

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

Delagated responsibilities, however, are a must.

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

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.

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

Yea verily.

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.