My Tryst with Software Quality ... 2015

Setting 1: 1975, IIT-Bombay

The 3-credit EE001 Computer Programming course. The semester was divided into two parts. The first involved a “high level language” called AKI (AvtoKod "Inzhener") – a Russian language that was poorly translated into its English equivalent ACE (Auto Code for Engineers) – that ran on an antiquated computer called Minsk-2 (http://en.wikipedia.org/wiki/Minsk_family_of_computers) and whose text-book-cum-user-guide-cum-reference-manual was a pack of cyclostyled (http://en.wikipedia.org/wiki/Cyclostyle_%28copier%29) pages stapled together.

In the first quarter of the semester, we practiced writing programs on paper, turned in assignments in that way, and were graded (on the bell curve) for accuracy and efficiency. “If” statements only had “then” clauses and not “else” clauses. There was a profusion of “Go to” statements, and every statement had to have a numeric “label”.

In the second quarter, we had access to CPU time. The programs were punched on imported (hence, rationed) paper tape, and there was no concept of a backspace to a punched hole. Handwritten programs had to be turned in at the counter of the punch operator, and the punched tape forms received the following day, along with printouts of the paper tape. We manually proof-read the printouts for punching errors. Depending on the number of punching errors, the manuscript was turned in again for another punched tape, or a “Change” tape was created for the errata in the first one. In the latter case, the “Change” tape had to be read in immediately after the original one.

Another day of anxious wait to see if the program would execute successfully. Most of the times, it would bounce on a syntax error, or a misread punched hole, or a torn tape in the reader. If the program did run successfully, it would go into an infinite loop, and one had to protect yourself from running out of the semester’s 15-minutes of CPU time quota with appropriate protections in the job control statement.

The second half of the semester involved programming in Fortran IV (http://en.wikipedia.org/wiki/Fortran) and a paperback textbook by Rajaraman. Punched tape gave way to punched cards – 80 columns on each, the first 6 for the label, the 7^th for a continuation symbol, 8^th through 72^nd for the line(s) of code, 73^rd through 80^th for comments! The cards were single-sourced from IBM, each student received 250 cards for the semester. As luck would have it, Emergency Rule was clamped on the country by the then Prime Minister Indira Gandhi, and IBM and Coca Cola were expelled from the country for not agreeing to dilute their equity with Indian investment. Punched cards went into further short supply! Code reviews became imperative – they took the form of students reviewing each other’s manuscripts and executing the statements manually to ensure that the program would yield the desired result, after it passed the hurdles of cards being successfully punched, punched cards not getting wet in the monsoon torrents, the deck of cards not getting dropped from the carrier of the bicycle onto the dusty road and rearranged successfully.

Setting 2: 1985, Blacksburg, Virginia

The DOS-PC has arrived. You can actually see what you write on a screen! Turbo-Pascal and Basic help with syntactical correctness!!!!

Setting 3: 1988, Bell Labs, New Jersey

Welcome, the world of Unix, get used to user unfriendliness! C and AWK (named after the creators and fellow employees Aho, Weinberger, and Kernighan), and the stream editor, sed! The breakthrough, though, is with the measurement of software quality, and the quality and version management system, SABLIME!

When a program provided unexpected results, an MR (Modification Request) was filed against you! MR was the respectable term that we call a “bug” today. An MR filed against you was a matter of disgrace, and ones salary merit increase and bonus payout was affected by the number of MRs that got filed against you! Real bottom-line impact, and a sureshot way to improve quality.

Then comes the philosophy of “make” – which took the human error element out of a deployment that involved multiple components.

Setting 4: Y2K

The race is against time to change two-digit years to four-digit years. The industry comes to terms with the millions and millions of lines of code that could catastrophically fail because the programmers never saw life beyond 1999. A pure, human neglect of foresight, that cost an immense amount of corrective action and its associated expense. Software quality started getting traded off for speed of implementation. Quality started becoming an after-thought cost, not an inseparable part of the line of code! I remembered the anecdote of the mechanical engineer who built a section of a roller coaster with a factor of safety of 0.75, because he said the ride is so fast that any accident would happen in the next section built by someone else!

Setting 5: Now

There is a reason why I am not putting a date on this setting. This allows this blogpost to remain current forever! It is a recognized fact that software has become so complex, that there will always remain parts of the code that will never get executed. Corner conditions that may never occur. And, if they do, the outcome is not tested. Because they will escape test cases, as well.

Software quality test coverage has become a statistics-based methodology, and automated regression and other forms of quality assurance are here to stay. Manual testing continues to have its place for products that are in rapid evolution mode. Quality assurance has become an industry in itself, and a respectable one, at that!

Alas, the days of the MR stigma are gone. Speed, cost, and quality have become the three-legged balancing act that struggles every day to remain level!

Quality By Design is the new buzz. Back to the future, I say!