We suggest really, really understanding the software infrastructure and architecture of the existing application prior to engaging in any parallel programming retrofitting efforts. Of course, this prompts emails to me and Tracey about the reality of costs and bottom lines and lots of talk about being practical and competing with overseas developers. We haven't even got to the formal methods yet, and we're hearing from bean counting nay sayers. We hear this kind of talk just too much."We're not trying to save the world here", "This is not a mission critical application", "We have a budget and deadlines to meet", "We simply can't afford the delay", "Maybe it'll be more cost effective if we just outsource the whole thing". That's one of the problems with software development. We'll accept and live with compromises that no other science or engineering field would tolerate. Make no mistake about it, software development has both an engineering and science component. It's to complex not to!

We've been giving talks on the use of formal methods in the process of adding parallelism or massive parallelism to an existing system, or when building a new system. Much of the feedback we get starts out with "Formal methods are only for large high-integrity systems", "This is not that kind of application", "This is not that kind of system", " We don't have the time, money, or manpower", "That's for mission critical systems". Poppy Cock! One man's piece of useless or barely useful data is another man's mission critical life saving information. We could be talking about grocery bill totals, student report cards, vacation days left, water bills, paternity tests, outstanding parking tickets, etc. A wrong answer in any one of those could mean life or death for someone, somewhere. I can remember a time where if my report card contained an 'F' where it should have had an 'A', we'd be talking about calling hours and whose gonna play Taps. My father was a demanding man. We can't put a price on someone else's information or service. It may not seem mission critical to you, but it may be to the end user (for whatever reason).

A law enforcement officer notices a car has a broken tail light. He enters the vehicle's license and up comes a list of erroneous outstanding parking tickets, the officer pulls the vehicle over, and ends up taking the driver to the station to work things out. In the mean time the driver is not their to pick up his autistic child from school. Because the father always makes it to pick up the child, the last person out of the building locks doors, turns off the lights and leaves the child standing in front of the school waiting on the father. Of course something happens to the child. Naturally there is blame to go around in this situation, but some piece of poorly designed software assigned parking tickets to a motorist that had none. These erroneous tickets turned what probably would have been a warning from the officer into a trip to the station, which created a crisis situation for the autistic child. Folks, this is watered down version of a true event. How harmless can a parking ticket report be?

As software engineers, architects, and developers, we have a moral and ethical responsibility to society and ourselves to produce software that is correct, reliable, robust, and safe. All systems, all applications have the potential to be mission critical if the right or wrong conditions arise. If formal methods, formal specifications, and software engineering techniques will guarantee the highest quality software possible, then that's what we have to use. Software development has its challenges as it is. When we introduce parallel programming into the mix we dramatically increase those challenges. It is software engineering malpractice to let end-user budgets, deadlines, profits, or threats to put us in the position of knowingly compromising software correctness, reliability, robustness, or safety. The engineering and the science is what it is. It is our charge to produce software that does not fail. That's a tall order, and to achieve it, we have to use whatever tools and techniques at our disposal that it takes. These tools necessarily include formal methods, specification, and software engineering. In response to some of the e-mail that we've received, we hear you, we understand where you're coming from, but respectfully, sir, maam, from where we stand, 'failure is just not an option'. At least for us it's not. We can't knowingly produce faulty software. That's unethical, immoral in some cases it should be illegal. Keep tight, maybe we'll convince you ...