Let start with the famous quote:
Insanity is doing the same thing over and over again, but expecting different results.
Incorrectly this quote is typically attributed to Albert Einstein. Click here for more details
What specifically does this have to do with software development? I recently purchased the book “Principles of Program Design” by M.A. Jackson. The book was first printed in 1975 – 48 years ago. I have only gotten through the preface and the first chapter. Couple of things where immediately apparent: First, the details are very dated, i.e. written in the era of mainframes, JCL, COBOL, FORTRAN, ALGOL, batch processing, punch cards, etc. Second, the more things change, the more they stay the same. Here are some excerpts that I was very surprised to find in a book written 50 years ago. At first, I laughed; then I gave kudos to Mr. Jackson for being insightful; then mild despair in that we – as software developers – are still repeating the same mistakes.
There are good programmers and there are bad programmers
Programmers who had previously written good monolithic programs now wrote good modular programs; programmers who had previously written bad monolithic programs now wrote bad modular programs.
The context for this excerpt was a discussion about Modular Programming (I tolded you the details are dated). If you replace “monolithic|modular programs” with the latest buzz words, paradigm, best-practice, etc. – the statement in my opinion still holds true today.
Don’t Optimize
We follow two rules in the matter of optimization:
Rule 1. Don’t do it.
Rule 2 (for experts only). Don’t do it yet – that is, not until you have a perfectly clear and unoptimized solution.
That fact I see the don’t-optimized mantra being actively advocated today indicates to me that we still have not taken this rule to heart.
Design before Coding
There is a kernel of important truth here: coding cannot be the first stage in building a program; it must be preceded by design.
If you have read any of blog postings (or my book) – you know how much I stress design (specifically software architecture and detailed design) before coding. I would like to say that in the world of commercial software/firmware that design always happens before coding, but it doesn’t.
Working Code is not Sufficient
The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work.
This is the first paragraph of chapter 1! Just imagine if the majority of developers had this concept baked into their DNA so to speak. What that would mean to the quality, reliability, robustness, etc. of software being produced today. Then we could Trust the Software Guys 😉.
Summary
A lot of progress has been made from the days of punch cards, batch processing, computers that required large climate controlled rooms, etc. Yet we seem to still be struggling with some of the same fundamental issues identified 50 years ago. Developing software is not (yet anyway) a hard science. In true ‘reuse’ efficiency – I point you to my previous postings below. I would like to think that 50 years from now, that there are not blog postings (or the modern equivalent) on why software developers are still making some of the mistakes from the 1970s.
- Never Trust the Software Guys: Engineer, Craftsman, or Artist
- Never Trust the Software Guys: Why is writing software hard?
How Good are You?
The photo below is an example program from the book. Extra shout out to anyone who can tell what the output of the program is.
