Back in 2019 I pushed out a quick snippet talking about why software seems to always be broken. Well if anything has proven since that time to have not corrected itself, this would most certainly be it. But why? We have so many people focused in this field currently that its hard to imagine that we haven't gotten better at producing higher quality software at this point but here we are. I put together a quick sampling below of things that come to my mind pretty quickly when I ask myself what has happened in the past 50+ years.
Early Programmers were Amazing
Everyone should read some of the early books produced by names such as Brian Kerrighan and Dennis Ritchie, Thomas Cormen et al, W. Stevens, and my personal hero, John McCarthy. These people were truly world changing individuals that really understood how computers functioned at the lowest levels and how to write code that not only worked, but worked in a very optimized manner. Unfortunately, I would venture to guess that if I walked into a CS101 class today and asked all the students if they read books by any of these people or even knew who they were that outside of possibly K&R, they would have no idea.
How can you know know where you are going, if you don't know where you originated from? The concepts that these individuals, I mean giants, present are still true today, and yet many people don't know very much about them, or even more painful for me personally, want to know anything about them.
Forgotten, Lost, and Ignored Wisdom
I recently started reading the Lisp 1.5 Programmers Manual and was so overtaken by the knowledge that McCarthy was trying to convey. Understanding what his vision was at the time and how the Lisp Interpreter is designed. For a programmer, its like looking at Mona Lisa as you can see the true beauty in what he was creating. Unfortunately now I see no beauty in the same way when I look at a significant amount of source code. Not so say there isn't still a lot of really good code in existence, but I do see a lot of sloppy copy/pasted code that in many cases, unfortunately resides in production systems.
I believe we need to understand these concepts that were hacked out years ago in order to properly move forward and improve on what our senseis have taught us. Without a basic understanding and the leveraging of their guidance we are destined to continually reinvent the wheel at best, produce inferior software in many cases, or as Jonathan Blow mentioned in the talk I highlighted in my prior post, completely lose that skill to time as has occurred in the past.
Features Verses Quality
If ignorance of software engineering principals wasn't enough, there is now a growing pressure to simply get features shipped and out the door. I suspect everyone reading this who has developed commercial software within an organization has some version of this story running through their mind as they read this. Oh yeah, this one time... we had to get this feature out the door due to the business promises that were made. Its OK, if that happened to you.. know that you aren't alone.
We Need to Ship Next Week, We Made Commitments
This is the classic business comment that frequently rears its ugly head. Was the development team ever consulted before the commitments were made? Was there a change in the requirements during the development cycle? Was there scope creep that appeared in the middle of the cycle? These are all questions that should be asked as to how it reached this point.
It's Only A Small Bug
This is one of my personal favorites... its a small bug, we can live with it in the short term. If you ever hear this red flags should appear immediately. I can guarantee this is going to reappear in some form in the future if a release is cut with "a known small bug", and there will be a major push that will bubble up to the stack as something that needs to be corrected before you can call it a day at some point.
We can Fix that in the Next Release
The immediate follow up to "its a small bug" is this statement. We'll get that next release. Somehow during the initial meetings of every development cycle after this time though, this small bug is always so insignificant that it just seems to fall by the wayside in support of some new feature that just has to get out the door in the upcoming release, because.... hey we made promises.
Well there you have it, a brief introduction of things that immediately come to my mind as I ponder this subject of software quality today. I suspect that some who read this will consider my thoughts are that of a paranoid crazy open source developer who just doesn't get the modern development process. That CI/CD and agile processes have fixed all of this. I will just answer that with one word, bull. If it were the case, I wouldn't be writing this, and you wouldn't have agreed with one or more of the issues I presented.
Also, I can say that I've had the pleasure to have worked in an organization at one point where code quality was truly put in the fore front. I won't mention the organization but it proved to me that it's possible to write really good high quality code. Believe me, it can be done but everyone involved needs to have that vision. Software quality is really like security at some level, its only as good as its weakest link. We owe it to ourselves and our customers that as the developers we aren't that weakest link. Its how the giants that we hopefully admire and maybe even wanted to emulate when we started down this crazy path of developing software would want us to be.
Until the next blog, don't talk about it...