Problem Solving Advice
Not to be confused with Troubleshooting
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
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
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.
|©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?
<A HREF="http://www.massmind.org/techref/problem-solving.htm"> Problem Solving Advice</A>
Welcome to www.massmind.org!