Randy Yates wrote:> 6. Be patient. > > Waiting for a system to be properly designed will almost always be > more efficient (time-wise) than "waterfall development," i.e., the > type of development for impatient managers that want to see something > almost immediately.I disagree. A better model (than either big up-front design or waterfall), in software development, is the spiral / agile model of development. I've found this model to be excellent, especially when the requirements change or are not fully elicited --- as they usually are in the sorts of software I've developed (greenfield ones). Big up-front design can be a killer when requirements change. For some reason, managers and customers seem to think that software can be changed much more easily than mechanical systems... so they do. The trick is to figure out when they're really expressing a new requirement, or just jumping on the latest Big Thing. I wholeheartedly agree with your previous point of keeping this as abstract as possible for as long as possible. This really helps the whole design and elicitation process.... without investing huge amounts of effort in implementing something that is not critical to success. Ciao, Peter K.
Best Practices to Manage Complexity in Hardward/Software Design?
Started by ●July 21, 2005
Reply by ●July 24, 20052005-07-24
Reply by ●July 24, 20052005-07-24
Fred Marshall wrote: ...> I agree. It was just that the original question was about best practices for > development and not for research. So, the responses were about development. > Then Jerry brought up "research" and we started a bit down that path. I > simply tried to say that changing the question would change at least some of > the answers. It's a bit harder for me to envision a product engineering > team deciding that failed tests were actually "OK" - although I know that it > happens. (e.g. see Richard Feynman's treatment of the space shuttle > disaster. Thus, I say "harder" not impossible). > > Maybe there needs to be another item on the list: > "Make sure there is good craftsmanship in every discipline"I didn't mean to sidetrack the discussion. My ought to have been more explicit: some exploration is inevitable for all but the most mundane projects. It surprises none of us that R&D has become a single concept. I recall choosing an ADC converter peripheral card with bipolar multiplexer whose specs suited the needs of a project well, only to find -- after the hardware was assembled and drivers written -- that dielectric storage in the holding capacitor made the sampler unable to follow the multiplexer at speeds well within the spec. Oops! (That time, I didn't have to start over. I found and fixed the problem and told the manufacturer how. They issued a recall and change order.) Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 24, 20052005-07-24
Rune Allnor wrote:> > Rune Allnor skrev: > >>Jerry Avins skrev:...>>>That's well put. How would you classify adding the two satellite plants >>>to the sewerage system? Originally, the system was designed with one >>>plant, and pipelines to it from all participating communities. One >>>administration blocked the two lines from the upstream communities, >>>forcing the Sewerage Authority to build the satellite plants. The >>>pipeline plans were scrapped, and we considered reducing the size of the >>>main plant. Is that a change of implementation, or of plans? >> >>That's certainly a change of plans, what I am concerned. >> >>Rune > > > My answer still stands, but I try not to use the word "plan" in this > discussion. In my mind, a "plan" is a list of things that need be done > in order to implement some system or strategy, or otherwise achieve a > goal. If circumstances change, the plan must change. Here, > "circumstances" > include both "implementation" and "design". > > Your original goal, make a sewerage facility to serve the community, > was still valid. The feasible way to achieve it changed. Hence your > change of implementation and of plans. > > When I talk of "changing goals" or "changing designs", I mean "changing > > the purpose" of the activity. It would be a "changed design" if you > started > out to build a sewerage facility but ended up building, say, a parking > lot > or a mall. > > I like to watch BBC's "Top Gear", a weekly TV show where new cars > are reviewed, tested and commented on. The hosts are very clear in > their opinions about what is good and what is bad. Particularly > high-profile brands and models (Ferraris, Porches, BMWs,...) are > put through their paces in the show. > > With these types of cars, one main reason for giving bad reviews is > often the purpose of the car: "The designers did not decide what kind > of car this would be. They wanted this to be a sports car. They wanted > this to be a muscle car. They wanted this to be a road cruiser. It is > none of the above". > > Of course, when the purpose of the car is undisputed, the hosts go > on to explain, in the most English way, why the purpose was not > achieved.You made my point, I think. "One plant downstream" can be either a plan or an implementation, depending on how long a view one takes. We had other design goals, not stated above. Among them, we wanted to avoid despoiling the countryside we live in. The main plant discharges into a river. When the inflow from heavy rains degrades the quality of the effluent, the river becomes a torrent that can accommodate heavy BOD* loading. Where before, one community's outfall caused periodic fish kills, now fish congregate just downstream of our much larger plant's discharge pipe. Not only is dissolved oxygen higher there, but the water is clearer than upstream. It's a great place to fish. The upstream plants pose a different problem. Both discharge into the headwaters of streams that, without their flow, would be dry for weeks at a time. Before the plants were built, fish and other aquatic life would ride out the dry spells in pools in the stream bed, and many would survive. (Some of the pools are spring fed.) Since they began operation, each upstream plant discharges about 0.3 million gallons a day of treated sewage into each stream. The streams never run dry. Clearly, for weeks at a time, there is nothing in the stream but sewage, and sewage is a major component at all times. We didn't want that responsibility. _That wasn't the original plan._ But the original goal gas been met: there have been no fish die-offs in the 25 years that the plants have been in operation. Kids swim and wade without harm; animals drink. _But we spend a lot more to treat upstream sewage upstream_ than it would have cost to send it downstream and treat it there. When the downstream plant operates normally, as it does an average of 363 days a year, its effluent tests purer than most bottled water. http://www.sbrsa.org/ Jerry ___________________________ * Biological oxygen demand -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 24, 20052005-07-24
steve wrote:> "A good designer should > avoid tying excessive investments of time or money to decisions which > are > likely to be undone later. " > > In other words designers have to be fortune tellers.Not all forecasting is prognostication. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 24, 20052005-07-24
Fred Marshall wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:Nf-dnavJit7de3_fRVn-ow@rcn.net... > >>Fred Marshall wrote: >> >> ... >> >> >>>You should have a process to prevent changes. Design freezes are a way >>>to do this. This avoids bringing in the latest and greatest idea and >>>perhaps even doing that again and again and again..... Then you should >>>probably have a higher-level process to embrace great ideas for change. >> >>I'm sorry, Fred, but that doesn't fly most of the time. Not only with >>electronic design, but with "simpler and more straightforward" (hah!) >>projects like bridges and buildings. As the chairman of the construction >>committee during the building of a regional sewerage installation that >>included a main plant, two satellite plants, three pumping stations, and >>over 40 miles of trunk line, I can tell you than no piece of the project >>was finished without change orders. The Mercury space capsules' audio >>amplifiers were changed twice after the design was thought to be final. >>First, to replace power transistors to increase allowable dissipation, >>then to correct the near disaster caused by the change. When you go to the >>market and discover that some ingredients are unavailable, you substitute >>other ingredients or change the recipe. > > > Jerry, > > You were the chairman of the construction committee. > You were in control of the "higher level process to embrace great ideas for > change". > So, you changed things when necessary. > I don't see any problem with that or any contradiction with what I said. > > In the context of what I said first: "better is the enemy of good enough". > That's when you need to freeze. For example: > > We have a filter requirement. We design a FIR filter that works fine. It > has been implemented and tested. Then somebody figures out that a few > memory locations can be saved and we can still meet the requirement with an > IIR filter. So, with no design controls in place, the designer decides to > re-design the filter. Hey, it's fun and the experience gained is great. > Except now the impulse response is longer and that affects parts of the > system that had already been tested and the difference shows up rather late > in the development cycle and the filter designer has gone and the FIR filter > is forgotten and people are wondering how to get back to what worked and > ...... you get the idea. > > I didn't say: "don't allow any changes". I said that freezing is good *and* > overruling the freeze process can also be good. I'm sure that many of us > have had experiences where things were controlled by idiots. That makes any > good idea look bad. It doesn't invalidate the good ideas. I think we're > back to Rune's suggestion that there has to be good craftsmanship. That > applies in management too. > > Here is a very positive story about design freeze: > > I took over a group that was building a rather complex board - of a design > that had never been done before. > Their plan was to build the board and then "spin" it - i.e. do a second pass > at the layout because they figured there would be changes, errors, things > that didn't work, etc. The second pass added precious months to the > schedule. > > So, I told them that we had to get first-pass success and that's what we had > to plan on. > They had to get it right the first time. > > The idea isn't exactly the same as design freeze but pretty close. The > design was "going to be frozen" in their minds so they had to get it right > the first time. > > They did it. Interesting, eh?We didn't appear to agree at first, but it seems we do. I don't subscribe to "If it ain't broke, don't fix it", but to a related maxim: "If you can see trouble coming, head it off." Another sewerage example: The upstream plants, the ones where failure turns miles of scenic brook into a sewage ditch, use a then-novel treatment scheme to make super-clean effluent. The process uses partly submerged rotating disks to achieve aeration and be a substrate for active bacteria. The supports for these disks were to be bolted to both sides of the concrete trough in which the sewage flows. I saw it going in, and questioned the wisdom of bolting steel to concrete that way. Differential expansion might tend to crack the concrete. Our consulting engineers had bought the patented design and used it "out of the box". When I questioned its longevity, I was reminded that prototypes had already been operating some four years with no problem. I remembered something else, and asked, "Where are they?" They were all in southern California, where the weather is quite different from here, central New Jersey. The bolts were already set into the concrete; what to do? The original plan was bolting each end with a half-inch pad under it. We bolted one end with its pad, and left a half-inch gap with no nut on the other end. That end is supported by the bolt, but not longitudinally constrained by it. Despite out harsher winters, there has been no cracking yet. But the California installations weren't "broke", so despite all subsequent installations using my floating hangers, the old ones weren't fixed. At least one original southern California trough is now patched. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 24, 20052005-07-24
Peter K. wrote:> Randy Yates wrote: > > >>6. Be patient. >> >>Waiting for a system to be properly designed will almost always be >>more efficient (time-wise) than "waterfall development," i.e., the >>type of development for impatient managers that want to see something >>almost immediately. > > > I disagree. A better model (than either big up-front design or > waterfall), in software development, is the spiral / agile model of > development. I've found this model to be excellent, especially when > the requirements change or are not fully elicited --- as they usually > are in the sorts of software I've developed (greenfield ones). > > Big up-front design can be a killer when requirements change. For some > reason, managers and customers seem to think that software can be > changed much more easily than mechanical systems... so they do. The > trick is to figure out when they're really expressing a new > requirement, or just jumping on the latest Big Thing. > > I wholeheartedly agree with your previous point of keeping this as > abstract as possible for as long as possible. This really helps the > whole design and elicitation process.... without investing huge amounts > of effort in implementing something that is not critical to success.I disagree with both of you. So there! (Disagreeing seems to be an activity that I do very well.) I could have written that you're both right. There are lots of models, and some people do better with one than with another. When the planning is up to you, but your boss picks the model, it's time to circulate your resume. I have never found a model that works for me that I can explain. My most productive mode is sitting with my feet on the desk and my eyes closed for a long time, consult a data sheet on occasion, and after a day or so of seeming inactivity, write down a plan. At meetings, I can't be that thorough, so I would usually listen at least half way through, longer if politics allowed (the thought just happens), and the opine, "I would go about it this way ....") I used to get called to participate in planning meetings for projects we all knew I would have no further association with. My advice was often followed, and sometimes backed up to. That's not to brag (but I acknowledge the form!), but to illustrate that my amorphous approach worked for at least one person -- me. I think it's good to know several planning paradigms, and to choose one that fits one's own style, and perhaps the project. As usual, the best way is acknowledging that there is no best way. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 24, 20052005-07-24
Jerry Avins skrev:> There are lots of models, and some people do better with one than > with another. When the planning is up to you, but your boss picks the > model, it's time to circulate your resume.Most certainly agreed.> I have never found a model that works for me that I can explain. My most > productive mode is sitting with my feet on the desk and my eyes closed > for a long time, consult a data sheet on occasion, and after a day or so > of seeming inactivity, write down a plan.Whoa, you are fast! I used to spend weeks in that mode. I am sure I would be the worst employer any "ambitious" boss could have, drinking coffe, reading papers and chatting with co-workers for days on end. No apparent activity, but if left alone (no bosses wanted to see "progress"), I always delivered on time and according to spec.> At meetings, I can't be that > thorough, so I would usually listen at least half way through, longer if > politics allowed (the thought just happens), and the opine, "I would go > about it this way ....") I used to get called to participate in planning > meetings for projects we all knew I would have no further association > with. My advice was often followed, and sometimes backed up to. That's > not to brag (but I acknowledge the form!), but to illustrate that my > amorphous approach worked for at least one person -- me.>From my experience, the truly amazing aspect in your story is thatyou were allowed to go on in this way, and that others acted constructively on you suggestions. This is the stage where the "fast trackers" usually find they need to make their mark on a project, and then do.> I think it's good to know several planning paradigms, and to choose one > that fits one's own style, and perhaps the project. As usual, the best > way is acknowledging that there is no best way.Rune
Reply by ●July 24, 20052005-07-24
Rune Allnor skrev:> Jerry Avins skrev: > > There are lots of models, and some people do better with one than > > with another. When the planning is up to you, but your boss picks the > > model, it's time to circulate your resume. > > Most certainly agreed. > > > I have never found a model that works for me that I can explain. My most > > productive mode is sitting with my feet on the desk and my eyes closed > > for a long time, consult a data sheet on occasion, and after a day or so > > of seeming inactivity, write down a plan. > > Whoa, you are fast! I used to spend weeks in that mode. I am sure I > would be the worst employerMake that "emplyee" Rune> any "ambitious" boss could have, drinking > coffe, reading papers and chatting with co-workers for days on end. > > No apparent activity, but if left alone (no bosses wanted to see > "progress"), I always delivered on time and according to spec.
Reply by ●July 24, 20052005-07-24
Rune Allnor skrev:> Rune Allnor skrev: > > Jerry Avins skrev: > > > There are lots of models, and some people do better with one than > > > with another. When the planning is up to you, but your boss picks the > > > model, it's time to circulate your resume. > > > > Most certainly agreed. > > > > > I have never found a model that works for me that I can explain. My most > > > productive mode is sitting with my feet on the desk and my eyes closed > > > for a long time, consult a data sheet on occasion, and after a day or so > > > of seeming inactivity, write down a plan. > > > > Whoa, you are fast! I used to spend weeks in that mode. I am sure I > > would be the worst employer > > Make that "emplyee"Or better still, "employee"... Rune> > any "ambitious" boss could have, drinking > > coffe, reading papers and chatting with co-workers for days on end. > > > > No apparent activity, but if left alone (no bosses wanted to see > > "progress"), I always delivered on time and according to spec.
Reply by ●July 24, 20052005-07-24
Rune Allnor wrote: ...> From my experience, the truly amazing aspect in your story is that > you were allowed to go on in this way, and that others acted > constructively on you suggestions. This is the stage where the > "fast trackers" usually find they need to make their mark on a > project, and then do.RCA Labs was a truly amazing place to work. In the midst of a research lab, I was a "consultant" whose contribution was making things work. My reputation was better than I deserved, but it (and three Outstanding Achievement Awards) gave me the freedom to act rationally. One of my suggestions, on controlling a machine vital to a high-priority project was turned town to my dismay. I wanted to use existing hardware (of my design, based on a Z-80) programmed in Forth. The project leader "knew" that success required a much faster machine (12 MHz 8086) programmed in C. He used Intel boards. I couldn't let personality issues sink the project, and I had the freedom to do it my way on my own. He had a team of three programmers who worked on the code for 5 weeks while the electrical interface was being built to the various sensors, switches, air valves, and transport motors. I had the drawings for that and the specs for some of what the controller had to do. (I had, on request, designed some of the algorithms. That's another funny story.) I wrote the code to do the job. The drivers for digital I/O were part of my design for the controller, completed long since. After a time, the design specs were changed (a flaw had been found) and I updated my code. Even after the update, I had only about ten days invested in programming AND TESTING. What happened when they first married computer to room-sized machine was a loud BANG as every relay and air cylinder was simultaneously actuated. Mercifully, a motor tried to run both clockwise and counterclockwise and blew the breaker. Still, some pushrods bent, and a few other pieces needed to be replaced. You see, the system had been designed by programmers, who naturally assumed that high must mean ON, and low must mean OFF. Hardware engineers design circuits to be active low, because I/O pins default to inputs on reset and remain high until programmed as outputs and then set low. Back to the drawing board! They changed the code, but I didn't have to. I had written it properly from the start and had a tech build a bank of inverters to match their wiring. Now I could discard the inverter board. After two more weeks of testing and recompiling after the repairs, it became clear that they wouldn't meet the deadline. I was asked to pitch in and assist. I unplugged their controller and plugged in mine. It worked right off, proving once again that a 4-MHz Z-80 is fast enough for almost anything that moves, and that knowing every bit of the code, including the compiler and the monitor ROM is a great help in avoiding mistakes and finding them when they happen. Three programmers working seven weeks didn't manage what I had done on my own in less than two. I'm not a fast programmer; I never was. I had several advantages, though. First, I had no one to argue with me about how to do it. (It's easy to reach a consensus alone. :-)) Second, I had experience writing software to do I/O to control hardware. I had even built an effective system to do that, and I used it for the project. The device drivers for it were bug free long before the project began. Third, I wrote in Forth, which let me test each code function -- rarely more than two lines -- as it was written, so that only correct functions were incorporated into subsequent code. Anyhow, my point is that the Labs gave me the freedom to do things like that, and succeeding at them earned me the freedom to do even more. Very few engineers ever enjoy the luck that I had. I feel especially blessed. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
