The Ego and the Shadow (or something)

An elementary examination of some software design (general system design) principles.

This’ll be brief as space allows. Something I’ve been mulling over for a good six months at least. The design of a program or the solution to a problem must be dissected into subprograms and subproblems. We don’t see this nearly enough. It should be one of the key ideas drilled into us from birth. You learn it in math, with the order of operations and some other early concepts. You learn it in long division and long multiplication to an extent. Still, it’s not nearly as clear as it should be. If you need to clean a room how should you proceed? Well first you need to define what the final state should be (ie, when is it clean?) If this is the kitchen then it’s clean after the floor is swept (or mopped), the counters and table are wiped, any food is stored, and the dishes are clean/put away. Bam. Right there we have four sub-problems and some early leads on child-problems for those. [Eg, (mop or sweep or (mop and sweep)), (wipe counter and wipe table), (store food in cupboard and store food in refrigerator), (dishes for dishwasher and dishes for hand washing)] How you attack the overall problem, be it by a combination of bits of work on each problem (Eg, working across the kitchen from one end doing each piece of each subproblem) or doing each subproblem in whole before the next, isn’t that important in most cases. Sometimes, though, you’re much better off choosing one or the other approach. That depends on the problems/subproblems. Optimization happens when you understand the problem enough to keep some work in progress at all times. Great chefs learn to do this out of necessity to have each dish ready at the right time. Anyway, that’s some preliminaries and I’ve tried to keep it short. Will continue later. Adios.

Please Deposit Two Cents: Cancel reply