Sometimes You Eat the Elephant; Sometimes the Elephant Eats You
This is actually a continuation of the series "Big Things are Made Up of Lots of Little Things." The title of this post is a correllary of that statement. The sub-title is a reference to the old riddle: How do you eat an elephant? (Answer: one bite at a time). It might also be compared with the old Elephant joke: How do you fit 6 Elephants into a Volkswagon? (Answer: 3 in the front, and 3 in the back).
As a programmer, I am often given a fairly large set of requirements for a software project. These requirements generally consist of an overall requirement and a set of features. For example, I was once given a set of requirements whose overall requirement was to provide a real-time visual picture of the environment in which a small aircraft was flying, in the cockpit of the aircraft, based upon GPS output, in 3 dimensions. In addition, there were a set of features. The visual output should also contain terrain information, aircraft information, and airport information. It should run on a laptop computer, running Windows Vista (code-named "Longhorn" at the time). It should use Microsoft Windows Communications Foundation (code-named "Indigo" at the time) to obtain various data over the Internet, using a satellite connection. It should display Flight Plan information. It should alert the pilot of impending terrain collisions. It should be configurable to display various combinations of these data, and various views of the aircraft. It should alert the pilot as to the location of the nearest airport, as well as the course heading to reach that airport, in case of the need for an emergency landing. It should display terrain elevation data in an intuitive, easy-to-read manner.
As you might imagine, this looked for all the world like a truly daunting task. I was given about a year to complete the project, and had no other developers working on it with me, except for a graphics developer who could create various graphics that I might need. So, here I was, facing the elephant, and getting indigestion just from looking at it. The elephant was looking hungrily back at me. I knew that one of us would eventually eat the other. I decided that I must eat the elephant, and not the other way around.
Thus began my process of analysis. Now, the word "analysis," as technical as it sounds, is not nearly so intimidating as it sounds. It sounds technical because it is most often used in technical disciplines, and that is merely because most technical disciplines involve working with complexity. To analyze the word itself, we can look to its' original Greek origins. In Greek, the word "analusis" means "a dissolving, or undoing," originating from the preface "ana-" (meaning throughout) and "luein" (meaning "loosen"). The literal meaning of the word "analysis" is to break down something "large" or "complex" into its' constituent smaller and simpler components. Big Things are Made Up of Lots of Little Things.
When one is given an elephant to eat, it is important to study the elephant first. It is not advisable to simply start eating; the task will quickly become overwhelming. One must formulate a plan. After all, one is not able to eat the entire elephant in a single byte (pun intended).
Now, the process of analysis is an iterative and recursive process. That is, one cannot subdivide the elephant into its' smallest manageable constituent components in one fell swoop. Rather, one makes increasingly smaller subdivisions, in a recursive loop. In the programming biz, this is often referred to as a series of "views" beginning with the 50,000-foot view, and progressively moving "downward" as the "chunks" get smaller.
You start with the whole elephant, looking at it from a vantage point at which you can see the entire elephant from all sides. It is not possible to see the entire elephant at this point, only the outside of it. But you can identify differentiated "parts" of the whole, and may start from there. It has tusks, a trunk, a head, a body, a tail, and legs. All of these are apparently different from one another. So, you move in with your machete, and make the first "virtual chops," separating the head from the body, the trunk from the head, the tusks from the head, the tail from the body, and the legs from the body.
Now you can move a bit closer, to examine the parts. You notice that the legs are similar to one another, both in terms of their shape and placement. Perhaps they may be treated in similar fashion, one to another. But what are the differences between them? Each has a knee and a foot. So, you chop each one in half at the knee and chop off the feet. You move closer, so that you can examine the components of each leg more closely. And so on.
Now, you move on to the head. But you think to yourself, those tusks look a bit simpler, perhaps I could give myself a break and deal with them first. Of course, you will have to deal with all of the elephant at some point, but you do have a choice as to the order in which you examine the parts.
Like the legs, the 2 tusks look almost identical. Unlike the legs, they are made up of a single piece each of a bone-like substance. You presuppose that the substance is indeed bone, and saw one in half to find out. It is indeed a bone-like substance, and it is virtually the same throughout. So, you see an opportunity to make a decision here, as further subdivision seems unnecessary at this point. How will you eat the tusks? After all, they are made up of a bone-like substance, and too large to fit in your mouth, much less your stomach. Looking at your tools, you decide that they may be ground into a powder, which can then be mixed with a fluid, and drunk. And that's one part of the elephant you have successfully analyzed. On to the next.
By this iterative and recursive process, the entire elephant is segmented and a plan for eating each constituent part is formulated. The only thing left to do is to implement the plan and start eating.
However, there is one last consideration to be taken into account. As you step back you see again that the elephant is huge, intimidatingly so, and you may even get a little dizzy by the thought of eating the whole thing. But it is not necessary to eat the whole thing. It is only necessary to eat each of the byte-sized (pun intended) pieces. The trick is to think only of the mouthful that is currently being eaten. So, in fact, we never eat elephants at all. Our lifetime is composed of very many byte-sized moments, and each moment is navigable in and of itself.
Interestingly, this very idea is expressed in the words of Jesus:
Take therefore no thought for the morrow: for the morrow shall take thought for the things of itself. Sufficient unto the day [is] the evil thereof. (The Gospel of Matthew Chapter 6, verse 34)
As a programmer, I am often given a fairly large set of requirements for a software project. These requirements generally consist of an overall requirement and a set of features. For example, I was once given a set of requirements whose overall requirement was to provide a real-time visual picture of the environment in which a small aircraft was flying, in the cockpit of the aircraft, based upon GPS output, in 3 dimensions. In addition, there were a set of features. The visual output should also contain terrain information, aircraft information, and airport information. It should run on a laptop computer, running Windows Vista (code-named "Longhorn" at the time). It should use Microsoft Windows Communications Foundation (code-named "Indigo" at the time) to obtain various data over the Internet, using a satellite connection. It should display Flight Plan information. It should alert the pilot of impending terrain collisions. It should be configurable to display various combinations of these data, and various views of the aircraft. It should alert the pilot as to the location of the nearest airport, as well as the course heading to reach that airport, in case of the need for an emergency landing. It should display terrain elevation data in an intuitive, easy-to-read manner.
As you might imagine, this looked for all the world like a truly daunting task. I was given about a year to complete the project, and had no other developers working on it with me, except for a graphics developer who could create various graphics that I might need. So, here I was, facing the elephant, and getting indigestion just from looking at it. The elephant was looking hungrily back at me. I knew that one of us would eventually eat the other. I decided that I must eat the elephant, and not the other way around.
Thus began my process of analysis. Now, the word "analysis," as technical as it sounds, is not nearly so intimidating as it sounds. It sounds technical because it is most often used in technical disciplines, and that is merely because most technical disciplines involve working with complexity. To analyze the word itself, we can look to its' original Greek origins. In Greek, the word "analusis" means "a dissolving, or undoing," originating from the preface "ana-" (meaning throughout) and "luein" (meaning "loosen"). The literal meaning of the word "analysis" is to break down something "large" or "complex" into its' constituent smaller and simpler components. Big Things are Made Up of Lots of Little Things.
When one is given an elephant to eat, it is important to study the elephant first. It is not advisable to simply start eating; the task will quickly become overwhelming. One must formulate a plan. After all, one is not able to eat the entire elephant in a single byte (pun intended).
Now, the process of analysis is an iterative and recursive process. That is, one cannot subdivide the elephant into its' smallest manageable constituent components in one fell swoop. Rather, one makes increasingly smaller subdivisions, in a recursive loop. In the programming biz, this is often referred to as a series of "views" beginning with the 50,000-foot view, and progressively moving "downward" as the "chunks" get smaller.
You start with the whole elephant, looking at it from a vantage point at which you can see the entire elephant from all sides. It is not possible to see the entire elephant at this point, only the outside of it. But you can identify differentiated "parts" of the whole, and may start from there. It has tusks, a trunk, a head, a body, a tail, and legs. All of these are apparently different from one another. So, you move in with your machete, and make the first "virtual chops," separating the head from the body, the trunk from the head, the tusks from the head, the tail from the body, and the legs from the body.
Now you can move a bit closer, to examine the parts. You notice that the legs are similar to one another, both in terms of their shape and placement. Perhaps they may be treated in similar fashion, one to another. But what are the differences between them? Each has a knee and a foot. So, you chop each one in half at the knee and chop off the feet. You move closer, so that you can examine the components of each leg more closely. And so on.
Now, you move on to the head. But you think to yourself, those tusks look a bit simpler, perhaps I could give myself a break and deal with them first. Of course, you will have to deal with all of the elephant at some point, but you do have a choice as to the order in which you examine the parts.
Like the legs, the 2 tusks look almost identical. Unlike the legs, they are made up of a single piece each of a bone-like substance. You presuppose that the substance is indeed bone, and saw one in half to find out. It is indeed a bone-like substance, and it is virtually the same throughout. So, you see an opportunity to make a decision here, as further subdivision seems unnecessary at this point. How will you eat the tusks? After all, they are made up of a bone-like substance, and too large to fit in your mouth, much less your stomach. Looking at your tools, you decide that they may be ground into a powder, which can then be mixed with a fluid, and drunk. And that's one part of the elephant you have successfully analyzed. On to the next.
By this iterative and recursive process, the entire elephant is segmented and a plan for eating each constituent part is formulated. The only thing left to do is to implement the plan and start eating.
However, there is one last consideration to be taken into account. As you step back you see again that the elephant is huge, intimidatingly so, and you may even get a little dizzy by the thought of eating the whole thing. But it is not necessary to eat the whole thing. It is only necessary to eat each of the byte-sized (pun intended) pieces. The trick is to think only of the mouthful that is currently being eaten. So, in fact, we never eat elephants at all. Our lifetime is composed of very many byte-sized moments, and each moment is navigable in and of itself.
Interestingly, this very idea is expressed in the words of Jesus:
Take therefore no thought for the morrow: for the morrow shall take thought for the things of itself. Sufficient unto the day [is] the evil thereof. (The Gospel of Matthew Chapter 6, verse 34)
1 comment:
Thank you for this. It gave me a bit of courage to begin thinking about planning to consider the beginings of the first stages of the analysis of a bit of programming I am just starting to think about doing for my Church's web site. A PHP programmer I am not. But the job needs doing, and who is is to do it? But it's so big! So daunting! So scary! I know to analyze its component tasks, but even that seems overwhelming. Your post makes it seem less daunting, less overwhelming. Thanks.
Post a Comment