Make everything as simple as possible, but not simpler.
-Albert Einstein
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'.
Posts
5 comments:
Wind Gatherer,
The top-down problem solving and structured programming religion has had more than its share of converts, but exercising that faith didn't avert Y2K failures, and often became an obstacle in overcoming the new mysticism that obsessed the originators of object orientation.
Freedom of expression in commanding computers to connect, combine, and control our lives has given way to protocols established to obviate originality and cut the cost of creativity in constructing the virtual reality that chains our imaginations to ever-evolving processor chips.
Stacks of Racing Forms have been replaced by PC-accessible data bases permitting past performance scanning and selection processing at unprecedented speed and volume; at levels of completeness and consistency impossible without non-human external CPU's and memory. Today's non-automated horseplayer is up against it even before he places a bet.
The playing field for the recreational bettor is further tilted against him by severely underpriced simulcast signals which have stimulated subversion of the pari-mutuel process. The situation enables off-shore ADWs to subsidize a select few extremely high-volume bettors through rebates on losing as well as winning wagers. This practice not only effectively lowers the takeout to which such players are subjected, but also undermines their competitors who get no such relief from current predominantly exorbitant direct takeout.
Perhaps racing would benefit from top-down problem selection if it were united under a central authority which could impose uniform regulations, but would we be happy with the innovations fostered by such standardization?
Indulto-
I don't disagree with anything you wrote and I wasn't trying to advocate for object orientation programming per se.
My observation, obtuse as it was, centered on the approach the industry seems to take to the problems it faces.
Do the individuals, with real power to effect change, approach the challenges as an abstract amalgamation, trying to digest the entire rotten corpse or do they understand the fundamental tenets of project management?
The examples I chose were just that. It was not my intent to claim OOD could solve any of those issues but rather the approach used to tackle writing code could and should be used to address the challenges the industry faces.
The difficulties you present are, without argument, concrete. But, I imagine, at the basal plain, the solutions involve the completion of simple-not easy-tasks.
The trick, as always, lies in identifying the real issues and working on their solution in a structured manner.
When parties, purporting to work on the issues take pot shots at each other in the media, regarding what to call the problem or where they should hold these meetings, it does not give me a warm fuzzy regarding their competence to actually resolve those issues.
As an outsider, it seems as if those parties are all too willing to advertise how diligently they are working on the issues. Were that the case, given the nature of the issues, they should not have so much free time to profess the fact.
I fear the Algonquin Round Table of industry leaders looks and acts much more like the panel of judges on American Idol than the architects of the Marshall Plan or the directors of NASA during the Apollo missions.
I hope you have a seat at this proverbial table because real problems require the admission of their existence, real solutions and the fortitude to enact them.
Thank you for weighing in.
WG,
You are an inspiration, not an irritant. Sorry I got carried away, but I’m always wary of substituting methodology for common sense.
With the simple heuristic of only branching downward, Knuth freed us from Dijkstra’s goto-less decree; resulting in cleaner, more obvious code. Bypassed by the OOP revolution, I am content within the confines of my capable dBASE/Clipper/FoxPro environment augmented by SQL. The rebel in me delights in each LOOP and EXIT command used to direct logic through modules mirroring functions and objects as elegantly as the artist in me permits without losing track of either time or the objective.
Watching the NYRA/NYCOTB debacle unfold we can only conclude that common sense, cooperation, and conscience are commodities in short supply compared with contention, corruption, conceit, and cluelessness as to both constituent and customer concerns. Other heuristics come to mind – smaller is better, less is more. Closing NYCOTB is a crucial correction, consolidating NYRA a cathartic coincidence.
There is no sport of Kings in Queens. Winter racing is an abomination that brutalizes both man and beast. The Wood Memorial should be transferred to one of the other two warm-weather venues for a pre-derby festival that celebrates the return of equine athletes with appropriate anticipation.
Loss of subsidies for green space producing animals devoid of competitive speed and stamina -- but still mandating subsequent pensioning -- is no casualty. Supporting better-bred specimens retired later following shorter seasons seems more sensible – and probably more profitable -- use of such resources.
Can we identify a problem worth solving when there are too many from which to choose? The trick, I suppose, is to break out of the endless loop wihout becoming broken-hearted.
This is a beautiful comment and response series and shows the strength of blog-readership response and input.
My wish is that the board members of the alphabet organizations had to read it every morning before breakfast.
They would not understand it, but if repeated long enough, some would sink in and might begin the process we all know is urgently required.
Keep up the great work, mates.
Frank
FM,
Assuming you are the e crafter of the sentence, “The significance of success as a sire of stallions is hard to overstate,” I’m hoping you’ll comment on the impact of the thoroughbred breeding program in New York State on racing there and on the racing/breeding industry as a whole.
Post a Comment