Program Quality Testing - "..putting the cart before the horse" - E.W.Dijkstra

[Sharathmg]

Hello All,

To the traditional software engineers, the name E.W.Dijkstra is one which evokes great amount of respect for the amount of work done in the field of computer science and software programming. Myself being from the younger generation was introduced to EWD( the short name used by Mr. Dijkstra in all his publications ) through his article where the GOTO statement was considered harmful. Lately, the speaker Bodil Stokke left me speechless with new revelations and insight into the works of EWD. As an afterthought, I tried to read through couple of his papers on software programming - ' The Programmers task Considered as an Intellectual Challenge' and 'Towards correct programs'. The statement that struck me most was, according to EWD, the quality assurance or testing procedure followed post implementation phase is akin to putting the cart before the horse. In this blog, I intend to dwell more into this statement and few other statements from EWD related to QA through testing and debugging.

We are all trained to believe in tried and tested frameworks. We are all schooled with the steps to success and also tend to devoted to this school of thought. EWD is known for proclaiming outrageous obituaries related to software programming which over the period have proved true. Out of experience, I have observed that QA process assists us in identifying the bugs in the solution. This implies that the bugs were inserted into the solution by the programmer as the programmer has the full control over the solution ( despite all the complaints by the programmer of it being controlled by customer/manager/colleague/HR etc... ). So, we insert the bug and then introduce the step to identify the bugs.

Going forward, we identify the bugs and log in the tracker. Later, the programmer burns the midnight oil or the midnight electricity to turn all the test cases from RED to GREEN. Then, we pass the solution as perfectly working and ready to use to the customer. If the testing phase is to weed out all the bugs then why do we continue to retain the support phase to track the bugs once in production? EWD says, "program testing can be used very effectively to show the presence of bugs, but never to show their absence". Testing is an important phase but we have given too much relevance to it for delivering a quality solution. It is one of the way to qualify a solution but not to ensure a quality solution. Quality is a thought which should be invoked when we begin the solution design process. Attempting to insert it at the fag end of the delivery process is a futile clean-up process. It is similar to outer cleanup of the new building where we can NOT do anything about the internal structure.

EWD talks a lot about the importance of understanding the internal structure of the abstract entities. We can never be able to generate and test all the possible test cases for the particular solution to determine its completeness. EWD believes that we have to arrive at a process of deduction akin to mathematics where we prove formulas based on the certain cases and if they are valid in those cases, we assure that other cases will also work. Well, its a complex thought and risky to totally resort to the above form of solution process. Also, its not suggesting that testing as procedure is to be abandoned. They are necessary tools/process in software programming. But, we have abserved that time and time again we have tried the old wine and it leaves the same taste in our mouth, Sour.

The programmer should think about the necessary features of the programming solution prior to implementation and not as an afterthought. We all tend to think of attributes of the program after its implementation rather than include it as part of the specifications prior to development.

One of the the reason behind the deep proliferation of these awful habits in the software industry according to EWD, is that the need to fulfill the growing need for software is fulfilled by call for more programmers, rather than the more capable ones, who could derive their greater capability from a better understanding of the nature of the programming task.

As I look back at my career, its baffling to see that inspite of all the warning signs given by the great software engineers like EWD from way back in 1960s and 70s, we are still stuck with the same old **** way of developing (Non)Quality software. Even now, we resort to the same steps and end up with same product. Agile or no-Agile we need a major shake up in the thought process. Its also upon the programmers to put the foot down and take up the mantle to ensure quality. If programmers are not qualified/interested in it then its upon the team lead/managers to push them towards it. Finally, its upon all of us to clean up the mess and put things in order. Its become like politics, as everyone who gets into it trying to rid it of corruption just gets corrupted by the system. As usual, we end up blaming the system. Hopefully, we can muster energy to swim against the tide and build some quality software.

Thank you All.

Dedication to the great EWD.

Regards,

Sharath