Not to be confused with Troubleshooting / Diagnosis.

It turns out that solving problems can be learned, and taught, and it can apply to all parts of our lives, not just our work.

## Divide and Conquer

Usually, if its a problem that hasn't been solved, its because its complex and its exceeded our complexity barrier, at least for the moment. To reduce complexity "divide and conquer". But how should we divide?

• Top down: Professors at MIT have called this "Wishful Thinking" because you can say to yourself "Well, this would be easy if I just had a function that could do this part of it..." and then you imagine that you DO have that function and wonder what would be inside it. This has the side effect of organizing your code in a very nice hierarchy. This is taught very intensively in "Structure and Interpretation of Computer Programs" ^
"Before implementing a component you write some of the code that actually uses it. This way you discover what functions with what parameters you really need, which leads to a very good interface. You will also have some good test code for your component."

""Wishful Thinking" is a good way to think about recursion: When seeing a recursive call, you should not think about the code being executed on each sub call. Instead, just imagine that the sub call does its job correctly. Thus, you prove the correctness of the function by assuming that it is correct (on simpler input). This is some positive kind of self-fulfilling prophecy. Of course you still have to check for trivial cases and need to assure that the recursive call handles a simpler case of your problem. But those are minor issues. The hardest part is to understand the recursive calls. Without the technique of wishful thinking, you can't handle problems like "Towers of Hanoi", let alone more complicated ones. "

• Bottom up: The "building block" approach. We know what abilities we have, and we can start using and combining them to build towards the solution we need.

• Middle out: AKA "Head On!" where we take on the most difficult part of the problem, or the part we least understand first and then the rest will fall into place. This seems counter intuitive, but it is actually the safest method because it keeps you from wasting time on simple things. See Iterative Design

• Vertical slice: In this method, you pick just one feature out of the many which must be included in your final design, and you implement that one feature completely. Usually, you start with an important feature, and implement its UI, its core, its back-end, but just one of many features. Its the bare minimum to demo it. It might be "minimum viable product". No frills, no fancy UI, just something that gets ONE useful thing to barely work. Then you pick the next feature and do the same with that. And then you try to integrate all those vertical slices together. Sometimes that works out nicely. Other times, the features don't fit together well since they have been implemented separately.

## Order of Implementation

How do we choose between these methods of dividing up complex problems?

• If they all seem about the same in difficulty, top-down organizes your code best so choose that.
• if we know how to do the very foundation and think we can just "build up" from there, then use bottom-up.
• If there's one part that we're thinking about a lot and are interested in it, go with that. (do what motivates you)
• The most experienced developers will start middle-out, taking on the "hardest part, the core guts of the problem" head on, and make that core issue the new complete problem to solve, and then recursively decide how to break that up. Iterative Design
• If there are parts that you think you can easily get help on, then we don't need to do those. Pick other parts that you alone need to be the one that solves it. Don't fall into the trap of doing the easy stuff first; always do the hard stuff first so you can fail quickly and often and then succeed in the over all task faster.

 file: /Techref/problem-solving.htm, 4KB, , updated: 2020/6/30 11:31, local time: 2024/6/12 08:52, TOP NEW HELP FIND:  3.236.142.143:LOG IN

 ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?Please DO link to this page! Digg it! / MAKE! Problem Solving Advice

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.

Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
 Did you find what you needed? "No. I'm looking for: " "No. Take me to the search page." "No. Take me to the top so I can drill down by catagory" "No. I'm willing to pay for help, please refer me to a qualified consultant"

 PICList 2024 contributors: o List host: MIT, Site host massmind.org, Top posters @none found - Page Editors: James Newton, David Cary, and YOU! * Roman Black of Black Robotics donates from sales of Linistep stepper controller kits. * Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters. * Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated! * Contributors: Richard Seriani, Sr.

.