Oceania is a health care company founded by physicians. The physicians worked in the emergency trauma center on weekends pulling a 48 hour shift. The income derived from this endeavor was more than enough to support themselves and to fund Oceania.
Oceania hired about a dozen college experienced but non-graduate junior-implementors. This team, over a five year period, generated an impressive demo of a physician-centric health care system based on the NeXT machine. The demo was impressive enough to obtain venture capital investment and three signed customers. An additional year passed with no shipped product; an experienced software engineer was needed.
There was no requirement document, no architecture document, and no testing paradigm. In fact, the system only contained the GUI. There was no database and no application logic. No wonder there was no product.
This situation is actually understandable. For the most part, customers are very GUI centric. What the customer sees on the screen, is the customer's total view of the rest of the application. The underlying infrastructure is assumed to exists if the GUI is present. A junior engineering team, lead by GUI-centric physicians, would build the best GUI in the world and not even realize the massive amount of missing code.
The software engineering process in place was cyclical in nature, only iterating on the GUI. This generated a wonderful GUI that could not be supported.
A more formal software engineering process was put in place. A requirement document and architecture were established for the GUI, the application logic, and the database components. A testing plan was put in place. The scope of the application was grossly reduced. The signed customers were replaced with a hospice. In this way, any error in the system would not have any affect on the outcome of any patient, since all patients in the hospice are terminally ill. The product was shipped and went live and was active for over a year without any customer discovered bugs.
The engineering process was turned back into the control of the physicians. Unfortunately, the physicians quickly reverted to their established previous behavior and the company had difficulties in delivering another successful deployed product.
There is a fundamental difference between the training of a physician and the training of an engineer. In the practice of health care, a physician must always base his decisions on the most current known information and protocols. As new information is discovered about the patient and as new procedures are established, the corrective actions that a physician takes are different than the corrective actions based on the outdated information. A physician acts in a non-monotonic fashion. Current information is much more important than past historical information.
An engineer, on the other hand, acts in a monotonic fashion. Actions are based on facts. Work accomplished so far should not be thrown out without significant reasons. A physician wants to base all actions on the most current information. Engineers need to base actions on all information, both current and past.
The conflict between the two paradigms was the root cause of major problems for Oceania. In particular, when one relational database vendor came out with a new product, the physicians wanted to immediately change over and throw out the work done on the other relational databases vendor product. The engineers agreed that the new release was better than the old release, but why throw out all of that work just for a little gain.
An important missing process concept in software
engineering methodology was apparent. Non-monotonic changes to a
system needs to be carefully managed. Some of the changes
are necessary and should be allowed. Many of the changes
are not important enough to delay the shipping of the
product. Even if the product does not have the best current
answer to all problems, a good answer is usually good
enough. See tables 7.11
and 7.12 starting on page
![[*]](cross_ref_motif.gif)
.
|