When software fails at the wrong time…
I recently had to take my pregnant wife to the hospital to treat a kidney infection. One of the first things we did after we got into a room was to answer an absolute torrent of medical questions. The nurse performed data entry into the hospital’s patient management software while she was asking the questions. The process took about an hour to complete. All the while my wife was not being treated and was in severe pain.
Now, had nothing gone wrong with the patient management system, the sheer amount of questions would still have taken at least forty-five minutes. I’ll grant that this time was necessary, especially because my wife is pregnant, to ensure that the diagnosis and treatment were done correctly. However, the extra fifteen minutes that my wife had to suffer through existed only because of failures in the patient management system.
The first problem was that the nurse was stumped when she tried to put in the answer my wife gave to a question and there was no drop-down entry for it. The question was “are you allergic to latex?” The answer, as so often happens in real life, was “sort of”. The nurse became aggrevated because the choices for her to choose from to enter the answer didn’t include an answer like that (which actually was that she is sensitive to latex). As a result, the nurse wasted time trying to force my wife’s answer into one of the application’s pre-defined choices. She actually resorted to trying to talk her into claiming that she has a full-blown allergic reaction to latex when that isn’t true! A poor implementation of software caused a nurse to do her job poorly. That is absolutely unacceptable.
The rest of the wasted time was due to some other glitches in the patient management system that weren’t as serious as serious. The application completely shut down at one point without an obvious cause. Later, the nurse had to re-type in a few sentence’s worth of explanation three times because the data wouldn’t save properly the first two times. Fortunately these events didn’t have as much of a negative impact on patient care as the first problem, but they did waste valuable time.
The point is that software developers should always strive to elliminate software failure, yet there are times when failure in software means more than just lost time and money. That critical failure, as in my anectdote, can cause extended suffering and loss of good, humane care when it is needed most. If you are a developer on such a software application then you should be ensuring that your software works correctly for real situations. This incident shows me that the software industry still fails to provide what people really need in real situations.
Programming under the Scientific Method?
Just as a good blog should be, here are some loose thoughts on programming that I’ve had lately. I have spent some time thinking about my process for writing code. In fact, I’ve been thinking about what I have been able to glean so far about the process that the mass of programmers in the world go through to write software. The impression that I have is that writing software is not scientific enough.
The germ of this idea is that I’ve never felt that I could quantitatively prove that the way I write code actually produces a working, correct result. This was before I really understood the idea of unit testing. I started going to conferences and working on a Masters Degree in Computer Science and began to learn about the idea of unit testing. Only at first, I thought that unit testing was the answer to qualitatively proving that my code was working and correct. Unit testing certainly appears to be the answer because of its emphasis on incrementally proving that the code is correct as per the rigor of each test. Yet, after about a year of actually working with unit testing I’m starting to question the true strength that unit testing provides.
There is no doubt that unit testing provides rigor around the software development process — theoretically. At any software development conference there is no shortage of unit testing pundits who espouse the benefits of the practice and explain the process for incorporating testing into your development process. And attending these conferences is largely a group of people whom have no doubt that unit testing is an honorable practice. Practically though, the test is usually only as strong as the will of the programmer to write a good test. The example being that I can write very poor unit tests for every unit either because I misunderstand the process or because I don’t care enough to write good tests. Neither is helpful in providing evidence of working and correct code. Further, even though the discipline of good unit testing can provide some proof that code is working and correct, there is almost no proof (I have only heard anectdotes) that starting the practice of unit testing actually changes the quality of software.
The failed panacea of unit testing for providing quantitative proof of working and correct code lead me to think about why it didn’t really solve the problem. Eventually the Scientific Method came to mind. When that happened I wondered why we don’t talk about the software development process in the context of such a solid framework? The Scientific Method works for all other sciences, why shouldn’t it apply to Computer Science?
So, finally, here is the main thought in this post. I believe that at least understanding the Scientific Method may improve the process of software development . In this post I won’t explain the Scientific Method or talk about how it applies to software engineering in a practical sense, instead, I’ll only mention that thought and leave it for you to ponder.
I think that the reality is that writing working and correct software is a grand challenge and requires rigor if it’s ever to become a standard. Great ideas such as unit testing (and its accompanying process Test Driven Development) undeniably add to the rigor or software development but fail to make a complete process for developing working and correct software. I’m curious to know if thinking about software development in terms of the Scientific Method would help bridge the gap between writing code and unit testing to make a cohesive process that can be analyzed and proven quantitatively.
…
There are a lot of scattered thoughts here that are either leaving gaping holes or need expansive exploration to fully explain. I understand that and I hope that myself or others can fill in those gaps. I’m immensely interested in exploring this idea and discovering where it leads.
