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.