Best Practices to Manage Complexity in Hardward/Software Design?

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

Reply to
steve
Loading thread data ...

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.

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

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

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

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

Reply to
Fred Marshall

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

Reply to
Fred Marshall

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

Reply to
Fred Marshall

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.

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

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

formatting link

  1. Implement from the bottom up.

  1. 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'" 
 Click to see the full signature
Reply to
Randy Yates

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

Rune

Reply to
Rune Allnor

Matt Timmermans skrev:

I know.

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

into practice.

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

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

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.

Rune

Reply to
Rune Allnor

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

Reply to
Steve Underwood

Rune Allnor skrev:

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

Reply to
Rune Allnor

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.

Reply to
Peter K.

...

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

...

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.

formatting link

Jerry ___________________________

  • Biological oxygen demand
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

Not all forecasting is prognostication.

Jerry

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

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

Jerry Avins skrev:

Most certainly agreed.

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.

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.

Rune

Reply to
Rune Allnor

Rune Allnor skrev:

Make that "emplyee"

Rune

Reply to
Rune Allnor

Rune Allnor skrev:

Or better still, "employee"...

Rune

Reply to
Rune Allnor

...

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

...

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.