Make everything as simple as possible, but not simpler.
Before turning to those moral and mental aspects of the matter which present the greatest difficulties, let the inquirer begin by mastering more elementary problems.
-Sherlock Holmes in A Study in Scarlet by Sir Arthur Conan Doyle
Except for simple problems, solutions consist of several pieces working together.
When writing code, the problem must be understood before the algorithm can be designed. Every decision should be designed before the code is written. This includes all parameters and aspects in which the solutions will apply and how they relate to each other once written.
Once understood the easy mistake is to write the whole code in one shot. The better, and in the long run, more effective manner, is to break each component down into individual parts and work on specific solutions independently.
You start with the original problem (Level 0) and figure out how can this be broken down into several subproblems (Level 1). Odds are, these individual Level 1 problems can break down into Level 2 and each Level 2 into Level 3 and so on. The trick lies in determining whether to break down each higher Level problem or continue with this algorithmic bifurcation to the lowest level (highest cardinal) component.
A rule of thumb says to pick the problem whose subdivision is obvious and continue in this fashion until the solution to each subproblem is so clear that it can be designed directly. By identifying the obvious problems, one is able to solve tasks that are relatively easy and the solution to other more complicated tasks becomes easier to discern. These more complex tasks, if approached in the same manner, prove easier to solve and one is able to complete the entire design without encountering any individual task that proves daunting.
The mistake, again, is to try to solve the entire problem all at once. Top down design works because it creates solutions for simple problems.
Building a solution from several pieces is simplified when approached individually. The first version of a solution is a working program with a single feature that is free of bugs. The program is saved and work continues on the next, easy to deliver, feature. That is saved and you work on the next. A working program with fewer features is always better than a nonworking program with everything under the sun.
David Allen, in his book Getting Things Done, advocates a similar approach to the execution of ones daily shuffle off this mortal coil. Pick a task, event, project, merger, acquisition...whatever, and break it down until you reach the point where you can complete one item on that list in under two minutes.
If I have to get my car fixed, that event is the end result of a series of individual tasks. I don't "get my car fixed"
I have to:
- Find the number of a mechanic
- Call the mechanic-or several
- Schedule an appointment
- Keep the appointment
Putting together a functioning, secure tote system or national regulating body of racing rules, could prove more challenging. Only if looked at as a whole.
At their core, projects are a series of deliverables accomplished by people by a certain time.
As Charles Emerson Winchester said, 'I do one thing, I do it very well, and then I move on'.