There was an Associated Press article in the Wilmington paper this morning (Monday 4/28) on the issues and problems of poorly written software. For me, it was (again) one of those times when I groan inside. Actually, since I was home and in private, I think I groaned out loud, because it directly related to my work and career.
The essence of the article was that poorly written computer software could be frustrating to its users and could potentially even cause serious injury or death. The article focused on what we call "embedded" software - programs that you don't see that run microprocessor chips hidden in many of our cars, airplanes, and appliances today. The article also went on to discuss software quality initiatives at Microsoft.
Since most of my career at IBM was in development of hardware and software for embedded or microprocessor-based systems, this struck very close to home and caused me to think back to the very early days of this business.
At IBM in the 70's and early 80's, we were very focused on the quality of our products. In the early 70's, there was a very powerful organization named "Product Test" which oversaw all activities related to the development of a product. These guys were bright and tough - although there was always somewhat of an adversarial situation between test and development, it was very much of a good thing as it resulted in a very high level of quality. They took our products and tested them very thoroughly.
Later, Product Test was restructured as Product Assurance. Assurance, as it was nicknamed, did not perform actual testing, but rather worked directly with development to ensure a quality product. I was less comfortable with Assurance than the old Test organization, but still the job got done.
In those days, the process for developing software was long and involved. It started with senior level design people who architected and designed the overall software flow. Individual programmers would then work on the low level design and coding of their piece of the software.
But the key thing was that code inspections were mandatory and accepted. When each programmer finished first their low-level design and later their actual code, the work was closely inspected by their peers and the senior designers. I remember hour after hour of sitting around a table laboriously going over line after line of code. I think it was a good process, and it worked well. But it added to the time to develop a new product, and certainly added to the cost of developing that product.
Sometime in the mid to late 80's, things changed outside of IBM. With the advent and popularity of the PC, the hardware cost of products tumbled. Since the software costs had to be linked to the hardware, these too had to plummet. The net result was that a company just couldn't afford to do the same level of design and testing that had previously been done.
Not only that, the entire development paradigm changed. Where once there was an emphasis on quality and inspection, the industry changed to the cult of the "young programmer". No longer was experience or quality the primary issue - staffing a software team was now going out to schools to find young graduates who could just spew out thousands of lines of code a week. The inspection process ground to a halt, because the attitude was that you couldn't understand these young programming whizzes anyhow, so why try.
There were actually some positive aspects to this. The old inspection process was replaced with today's "team" concept - basically the same thing, but giving the group more freedom to develop its own quality process. But the new system still had too much autonomy for the individual programmers.
Now, finally, the pendulum is swinging back, at least at large companies such as Microsoft. An emphasis on quality and security has emerged, even if it causes the delay of software delivery. I see a brighter future for our software in the days ahead.
(Bob Seidel is a local computer consultant in the Southport / Oak Island area. You can visit his website at www.bobseidel.com or e-mail him at bsc@bobseidel.com).