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
Best Practices to Manage Complexity in Hardward/Software Design?
Started by ●July 21, 2005
Reply by ●July 21, 20052005-07-21
<jjlindula@hotmail.com> wrote in message news:1121970065.257771.127820@g43g2000cwa.googlegroups.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 >
Reply by ●July 21, 20052005-07-21
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 ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Reply by ●July 21, 20052005-07-21
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
Reply by ●July 21, 20052005-07-21
jjlindula@hotmail.com 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
Reply by ●July 21, 20052005-07-21
jjlindula@hotmail.com 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.
Reply by ●July 22, 20052005-07-22
<jjlindula@hotmail.com> wrote in message news:1121970065.257771.127820@g43g2000cwa.googlegroups.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
Reply by ●July 22, 20052005-07-22
jjlindula@hotmail.com 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, > joeJoe, 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. �����������������������������������������������������������������������
Reply by ●July 22, 20052005-07-22
On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> 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
Reply by ●July 22, 20052005-07-22
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in news:sdu0e1h5or9d6dbe6akavdov7bnqh6c9ld@4ax.com:> On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> 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
