[Tutor] decomposing a problem

[Avi Gross]

Mike,

Excellent advice.

I find that many people are fairly uncomfortable with abstraction and tend to resist a pure top down approach by diving to any solutions they may envision. For example, if you say things like create a data structure that can hold as many kinds of information as will be needed. The data should be able to be viewed in several ways and adding a new item should be fast even if the number of items grows large ...

Some will have stopped reading (or creating) and will jump to deciding then need a dictionary. Others may want a deque. Some may insist they need a new class. 

But wait, if you continue reading or designing, it may be clear that some choices are not optimal. Heck, it may turn out some design elements are contradictory. As someone asked on another python list, is there a better way to get a random key for a dictionary. Well, not easily without expanding all keys into a list of perhaps huge length. Followed by a search of much of that list to get the nth index. So maybe a plain dictionary does not make that easy or efficient so do you give up that need or use some other data structure that makes that fast? Perhaps you need a hybrid data structure. One weird idea is to use the dictionary but every time you generate a new key/value pair you also store a second pair that looks like "findkey666": key so that a random key of the first kind can be found in constant time by picking a random number up to half the number of items, concatenate it to "findkey" and look up the value which is a key.

When you try to work bottom up with students, some see no point as they are missing the big picture. I used to work during graduate school writing PASCAL code for a company making flexible manufacturing systems and my job often was to read a man page describing some function that did something minor. I often had no clue why it was needed or where it would be used? I was sometimes told it had to FIT into a certain amount of memory because of the overlay technique used and if it was compiled to something larger, was asked to break the function down into multiple functions that were called alternately .... Sometimes an entire section had to be redesigned because it had to fit into the same footprint as another. That was the limit of the big picture. A shadow!

What I found works for me is a combination. I mean teaching. You give them just enough of the top-down view for motivation. Then you say that we need to figure out what kinds of things might be needed to support the functionality. This includes modules to import as well as objects or functions to build. But that too can be hard unless you move back into the middle and explain a bit about the subunit you are building so you know what kind of support it needs closer to the bottom.

I admit that my personal style is the wrong one for most people. I do top down and bottom up simultaneously as well as jump into the middle to see both ways to try to make sure the parts will meet fairly seamlessly. Does not always work.

How often have we seen a project where some function is designed with three arguments. Much later, you find out some uses of the function only have and need two but some may have additional arguments, perhaps to pass along to yet another function the second will conditionally invoke? It may turn out that the bottom up approach starting from one corner assumed that the function would easily meet multiple needs when the needs elsewhere are not identical enough. If they keep demanding one function to master all, you can end up with fairly awful spaghetti code. Of course python is not a compiled language like C/C++ and PASCAL and many others were. It is often fairly easy in python to have a variable number of arguments or for the same function to do something reasonable with multiple types and do something reasonable for each.

One thing I warn people about is mission creep. When asked to do something, try not to add lots of nice features at least until you have developed and tested the main event. I have seen many projects that did feel the need to add every feature they could imagine as there remained keys on the keyboard that did not yet invoke some command, even if no customer ever asked for it or would ever use it. Amazing how often these projects took too long and came to market too late to catch on ...

Some of the people asking questions here do not even tell us much about what is needed, let alone their initial design plan. It can take multiple interactions back and forth and I wonder how many give up long before as they just want an ANSWER. 

In case you wonder, I am reliably told the answer to life, the universe and everything  is 2*21.

-----Original Message-----
From: Mike Mossey <mike at pathtomathclarity.com> 
Sent: Tuesday, December 25, 2018 9:49 PM
To: Avi Gross <avigross at verizon.net>
Subject: Re: [Tutor] decomposing a problem


> On Dec 25, 2018, at 4:00 PM, Avi Gross <avigross at verizon.net> wrote:
> 
> [Long enough that some should neither read nor comment on.]
> 
> Mats raised an issue that I think does relate to how to tutor people 
> in python.
> 
> The issue is learning how to take a PROBLEM to solve that looks 
> massive and find ways to look at it as a series of steps where each 
> step can be easily solved using available tools and techniques OR can 
> recursively be decomposed into smaller parts that can. Many people 
> learn to program without learning first how to write down several 
> levels of requirements that spell out how each part of the overall 
> result needs to look and finally how each part will be developed and 
> tested. I worked in organizations with a division of labor to try to 
> get this waterfall method in place. At times I would write 
> higher-level architecture documents followed by Systems Engineering 
> documents and Developer documents and Unit Test and System Test and 
> even Field Support. The goal was to move from abstract to concrete so 
> that the actual development was mainly writing fairly small functions, often used multiple times,  and gluing them together.
> 
> 

It’s an interesting topic, getting students to decompose problems. 

As a tutor of programming (I use mainly Python), I try to get students to describe a problem at a high level with pseudocode and/or English before attacking the details. 

Both my programming and math students tend to overcomplicate things. They can benefit greatly from using simpler ideas. 

When they write an English description of a problem and their proposed solution, I try to get them to use fewer words and to use big fuzzy concepts. I try to get them to describe a problem in terms like “we take 2 lists, combine them, and filter the results.” Their normal instinct is to describe a problem like that with several sentences or even several paragraphs, meaning they are bogged down in the details.

Then I have them break down the problem further and gradually write English documentation or pseudocode with more details. 

We also use bottom-up design sometimes, like taking just one piece of the problem and solving it as a learning experience. With bottom-up, again I try to simplify it for them by having them not worry about the big picture. Don’t try to relate everything to the whole problem but just take details one at a time, and assume that you are writing a little test algorithm. We can discover the relationship to the whole problem over time, and we might rewrite or even abandon our experiment.

Mike