Today, I finished reading a rather old book. It was published in 1961. It’s about computer programming. So, what can you learn from a 50 year old book? While reading it, I got in touch with one of its authors, Jerry Weinberg. He seemed pretty astonished that even after 50 years someone was still reading one of his earlier works. Besides the fact that the book Computer Programming Fundamentals by Leeds and Weinberg was one of the first books to mention software testing at all, I got many more nuggets of wisdom out of it – astoundingly still valid, even half a century later. I decided to share my insights with others.
While the main content is about the 7090, an early computer with four tape channels, some registers, and quite a bit of memory – compared to today’s standards of computer technology. Half a century back there were no higher-level programming languages (yet). Instead the 7090 was programmed using assembly language – instead of directly using the numerical opcodes. The final chapter also mentions early attempts of multitasking. The text reminded of the two books in the Write Great Code series as well as the book Computer Organization and Design – The Hardware/Software Interface. From my perspective it was a wonderful reminder on those essential books I read five years ago.
Despite the technology shift, I was amazed by the methods. Leeds and Weinberg introduce flow charts to document the necessary steps before the programming begins. Flow charts helped to sort out the programming problem, but also to realize whether or not the program was complete. If a box lacked outgoing arrows, or there was a final state missing, one could clearly see from the flow diagram, that the overall design was not ready to be programmed at all. But, as I read on, I could also see that flow charts had undergone a state where they were adapted to higher level programming. Reflecting back on the half century, I think that in the history of our profession of software development we have tried to stick with the flow charts from early days up to the late 1990s when it got replaced by the Universal Markup Language (UML) constructs. Reflecting back on the first job I got in 2006, our designers and architects were using flow charts for a majority of the documents. This might speak for flow charts, or against innovation in documentation in software development. Take your pick.
While reading the book, I tried to collect some of the phrases which I wanted to keep. While I could reprint the whole chapter on testing (30 pages), I would like to focus on some smaller sentences.
The first one I would like to pick is on flow charts.
One of the more dangerous occupational hazards in computing is the habit of working out a set of diagrams, formulas, and figures until some impressive statement like “twice as efficient” emerges.
We have gone very far with pictorial documentation like UML diagrams and neat forumlas. The problem with these diagrams and formulas is the notion to attach an interpretation about efficiency to it. Take code coverage as one of these examples. You get a pie chart with the interpretation that 100% code coverage is better than 80% or 50%. But still doesn’t code coverage tell you anything about the code that was missed to be written, or how good the tests covering the actually are. In fact, you can achieve 100% code coverage with tests that exercise the code, yet, lack to assert anything on the results. As long as all the code is executed, the coverage is perfect about it.
If we have mastered a few of these fundamentals along with the habit of curious exploration, we can rediscover special techniques as we need them.
Fundamentals are essential – fundamental you could say. Still having fundamentals alone does not mean that they will bring you all the answers. Without the curiosity to discover new things, you will get stuck with the fundamentals, exercising them brainlessly for the next four decades. Instead, follow your curiosity, and explore new way and techniques that aid you in your quest. The choice is up to you, I prefer the professional pick. In order to master techniques in software development, I have to keep my curiosity, and my sense for interesting things.
But Leeds and Weinberg also refer to clean code:
If we produce a new vocabulary word (subroutine) we must not produce something sloppy or something that may be misunderstood or misinterpreted.
If we define a subroutine, a function, a method, we should not be sloppy about giving it a good name that is unambiguous. This starts with the name of the method and the class, and continues to the layout and readability of the function. This is one of the two biggest problems in programming: naming, cache invalidation – and off by one errors.
But the references to software craftsmanship go further than that:
Knowledge of only the instructions on a computer will permit one to code; but to be a programmer of any professional standing, computer operation must be understood.
In this paragraph Leeds and Weinberg refer to the whole team approach. A good software developer not only knows about programming, but also about operation, testing, and business analysis. We have to be aware of the human factor in our profession. While early operators could make errors because they are human, today’s program users are not relieved from the human nature of making errors. Our systems have to compensate for these errors. This means that we have to bring a diverse experience to the table if we want to succeed at programming a good computer system.
In the end, I held back my most famous quote from the book, which still applies. I took it from the front of the book within the first 20 pages, and it’s a very contradictory and controversial rule in its own, but reflects the biggest flaw of our profession from my point of view:
All good rules should not be applied with unthinking faith.
Whenever rules stop to serve our purposes, we should stop applying them with our brains switched off. I still hope some of us learned this lesson years ago, but on a daily basis I can see people falling for this. If we train ourselves to transform these rules into guides which we can pick when they apply, we can improve a lot in our profession of software development.
I’m looking forward to the next half century of lessons in software development, and hope that we will continue our journey in this exciting technology without failing to too many fallacies we have crossed in the past.
It sounds like an interesting read, Markus. Thanks for sharing your experience and the quotes.
I think I was first introduced to computers when I was less than a year old, back in 1969 or 1970. My father lectured computer science at the Technical University of Denmark back then, and from 1971 or so, worked at Regnecentralen, the first Danish computer manufacturer. My father and I recently participated in the celebration of the 50 year anniversary of the first series manufactured computer: GIER, which was similar, though smaller in core memory size to the 7090 – but much, much cheaper.
The people working with GIER were not using structured approaches: Their CEO urged them to “play” at work and the machine was built in a small house in Copenhagen by (considering its complexity) a surprisingly small team of people.
The Algol compiler was the largest software product they made: It was delivered on a large roll of paper tape and designed as a 9 pass compiler so it could fit in the 1024 word x 40 bit core memory. Quoting from a note from a conference in 1962:
“In designing the Gier Algol compiler the primary considerations have been the generality of the language, speed of compilation, and thoroughness of error detection. However, in the course of the work it turned out to be possible to satisfy all reasonable requirements on the quality of the compiled program as well.”
This pretty much sums up their approach to programming: Instead of suggesting structured methods as the way to build “quality”, they focused on the programming language (the tool set), allowing “users” (i.e. programmers) to express themselves more freely and intuitively. Algol is a language very similar to Pascal – and you will probably agree that a well written Pascal program is just as readable and structured as any flow chart will ever be. Unlike early FORTRAN programs!
And where the flow chart needs to be converted into machine readable code by hand, the Algol program can be fed directly into the computer.
I’ve been literally brought up with this approach and my father never missed a time comparing the culture of the small, innovative Danish company Regnecentralen with the “big and inefficient” IBM. He clearly felt “his” company was superior in every way!
Whether he was correct or not isn’t important. My point in sharing this is that there was a multitude of directions in computing already back in the very early 1960’s.
Cheers,
Anders