Home Some Thoughts on the Passing of Dan McCracken (1930 – 2011)

Some Thoughts on the Passing of Dan McCracken (1930 – 2011)

There is a missing characteristic to most of what is published today on the subject of computing. At some point in time, as a matter of course, we stopped treating the subject with respect and reverence, and we started adorning it with buzzwords, marketing promises and metaphors borrowed from the self-help department.

What Daniel D. McCracken managed to accomplish as early as 1957 was to give the knowledgeable layperson a foundation for understanding business processes in terms of procedural mathematics. As a young author decades ago, I studied McCracken’s methods and I attempted to take his lessons to heart. In some of my first books on Visual Basic, I was inspired by McCracken to demonstrate a relatively simple concept using a substantively more complex tool: I demonstrated program control using sort algorithms.

McCracken did this from the very beginning, and he may have mystified his audience as much as I did mine. But he performed a necessary task, and he was probably the first to do it. He showed how a complete program that performs a complex function is developed from the core out. Although the concept was probably born in the first IBM laboratories to put FORTRAN to use on a daily basis, McCracken was the first to demonstrate a concept borrowed from artistry: the ability to see the complete product holistically, build working models instead of partial fragments and keep it working with each implementation.

McCracken knew exactly what he was doing – the man reasoned on all levels at once, as evidenced by his later treatises on public policy and theology. In this excerpt from his 1975 paper, “How to Teach Structured COBOL to Beginners,” McCracken reiterates the principle he had already, by that time, been putting to use in his classroom and his published work for two decades. What he said, and how he said it, has not in the nearly four decades since.

Structured programming, for the purposes of this paper, may be defined as a style of programming in which only three logic control elements are used, namely, sequence, selection (IFTHENELSE), and iteration (DOWHILE). The scope of control of each selection and iteration element is displayed by consistent indentation. The use of only three logic elements applies both to coding, using whatever logic elements the chosen language provides, and to program design, which is done using either structured flowcharts or, preferably, some form of pseudo-code. A complete program design is achieved in a series of approximations, beginning with a simpler problem from which the desired design can be developed, in a process commonly described as stepwise refinement.

The goal of structured programming is the production of programs that as clearly as possible display their structure, i.e., the interrelationship of their parts. This clarity is a primary benefit of the restriction to only a few logic elements, which leads to programs that can be read in a “top-down” fashion, that is, without skipping around through the program. The purpose and function of any program statement can generally be understood by looking at only a few other statements, all physically close by, which is very seldom true of programs written by conventional methods. The main drawback of GO TO statements is that they tend to destroy this locality of context.

The design and coding stages of programming may or may not be shorter when structured programming methods are used, but the check-out and maintenance phases are generally much faster and easier to manage since programs are easier to understand. As a result overall programmer productivity tends to increase, sometimes by a dramatic factor.

There is a missing characteristic to what is said about computing, but nothing at all missing about what is meant by the finest of its practitioners. Daniel D. McCracken gave the world six wonderful decades of brilliant explanation, most of which today is buried in barely accessible texts and vastly dispersed libraries. Most of it is treated as obsolete. A great deal of it, however, is about as obsolete and inapplicable to the current age as the three brilliant, illustrative paragraphs cited above.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.