Project 11 - Problems Solving Techniques (part 4)

The hierarchy method is simply demonstrated by the diagram on the right. Every component is dependent on one above it, with the exception of the highest component. Designing programs in this manner makes them easier to read, modify and extend. This style of planning is very common in engineering of all types, though one good example is the file systems provided by operating systems. File systems have a top-level (or root), and underneath that root are directories (like Program Files or Documents and Settings) and underneath those are more sub-directories. Properly defined levels in a hierarchy structure allow you to work with one level without necessarily knowing about any other level. Each level is a defined abstraction of some idea, concept or classification. With the abstraction and hierarchy a programmer doesn't need to know what any command does or what it is documented to do, just that it does it. This allows the programmer to build more and more complicated structures, one on top of the other.

For instance: you can make a program to draw a street, which is built off of a drawHouse class, which is built off of drawFront, drawRoof, drawDoor, and drawWindow classes. The only thing you need to know to modify the program is what the inputs to drawHouse are, you don't really need to know how the other classes underneath it function, as long as you know how to use them.

To use this goal in real life, you need to start out with some kind of ultimate goal. Once you have that, move down and figure out all the parts you would need to accomplish that goal. From here, you build down from whatever your goal is to smaller bits and parts and divide that up between people so they can each work on those parts and the work is a lot easier on each person than it would be making everything yourself.

This would be a good way to plan things well in advance due to it's capability for additions and modularity. Planning a conference well out in advance, for instance, some new things may come up that you want to implement, but the basic idea would remain the same and you could add or remove as needed to achieve making the best possible conference. Say you had a speaker scheduled to speak on a certain topic, and they had to cancel. If you've laid out what you wanted, you can look back at this and take that particular talk out and see what you could replace it with as it pertains to other things. Like, say the talk was about courage, you could replace it with someone talking about integrity (assuming you didn't already have said talk, in which case you would know because you have everything laid out). If you define each part of what you want to do well, you can also split up the planning work between several people so that they can all take a part.