Rebel Science News
11/28/2012
Jeff Hawkins Is Close to Something Big
 
8/26/2012
The Myth of the Bayesian Brain
 
8/23/2012
The Second Great AI Red Herring Chase
 
8/15/2012
Rebel Speech Recognition Theory
 
8/8/2012
Rebel Speech Update
 

The Silver Bullet News

To Drastically Improve Software Reliability and Productivity

Latest News and Issues (September - October 2004)

 
Rebel Science Home
Why Software Is Bad
Project COSA
Operating System
Software Composition
Parallel QuickSort
The Devil's Advocate
COSA Discussion Forum
Not Associated with V.S. Merlot, Inc.
Contact Me

 

This page is where you will find short news articles and other musings related to the Silver Bullet hypothesis and Project COSA. All articles are listed in the reverse order of their date of publication.

More Recent News

October 2004

10-26-2004

Bitter Medicine
What's in it for the Industry?
What's in it for the Government?
What's in it for Me?
What's in it for the Investor?

10-07-2004

Event Handling
Total Vision

10-02-2004

Data-centered Software Systems

10-01-2004

The COSA Reliability Principle (CRP)

September 2004

09-30-2004

The Elimination of Blind Code
No More Unforeseen Side Effects
Embedded Systems Programming

09-26-2004

Software Design vs. Hardware Design
Jeanne Missed Miami

09-24-2004

Mean Jeanne

09-23-2004

COSA Business Models

09-21-2004

The FAA Is at it Again
The Ancient Curse of the Algorithm
Leapfrogging the Competition
International Standards Organization

09-20-2004

The Sustainable Careers Consortium (SCC)

09-14-2004

Computer Geeks: the Neo-Luddites?

09-13-2004

Intel vs. AMD
Silver Bullet Discussion Group
09-10-2004
NASA's History of Software Failures
09-09-2004
Open Letter to CyLab (2)
09-04-2004
Open Letter to CyLab (1)
09-02-2004
Hurricane Frances
09-01-2004
Closing Down
Von Neumann Architectures
 

 

October 26, 2004

Bitter Medicine, 12:10 AM EST

The Silver Bullet site has received thousands of visitors from all over the world in the last few months. This is good news because it is a sign that the COSA software model is being seriously discussed as a possible cure for unreliable software. Of course, COSA has the "dark side of the force" (to borrow an expression from Star Wars) to contend with. It must overcome the naysayers, the knee-jerkers, the not-invented-here crowd, the false prophets, the snake oil salesmen, the know-it-alls, the plagiarizers, the paranoid investors and the merely clueless. And let us not forget those who have long ago given up on a cure. But as evidenced by the number of return visits to the site, no amount of prevarication, ignorance or ill will is going to keep thinking people from making up their own minds.

The dark side is certainly a force to be reckoned with. It will put up a fierce fight and use every dirty trick in the book to hold on to the status quo for as long as possible. But it is all to no avail because, in the end, it will lose the war. It will lose for two principal reasons:

a) The cost of the software reliability problem to society in terms of money, time and human lives has already reached an unbearable level and continues to grow unabated.

b) As it continues to gain recognition and respect, the COSA model will prove to be so inescapable and so self-evident a solution to a nasty old problem that the computer industry will collectively kick itself in the rear for not having understood and embraced it fifty years ago.

The question is, how much more pain is the software community willing to endure before it finally agrees to take its medicine? Let's examine some of the advantages and disadvantages from the point of view of the various players.

What's in it for the Computer Industry?

Well, there is good news and there is bad news. The bad news is that there is no doubt that COSA will eventually eliminate the entire software reliability industry. The reason is that every business will be able to develop its own robust software applications in record time. No doubt, this will be bitter medicine for many.

But the good news outweigh the bad news, in my opinion. First off, COSA will re-energize the computer hardware industry: we will need a whole new breed of fast CPUs optimized for signal-based, synchronous software. Second, COSA will open up software development to a large segment of the population who were previously excluded from participating, the end users. I foresee an upcoming explosion in software creativity and productivity, one which will make the golden days of the eighties pale in comparison.

What's in it for the Government?

I am not a believer in big government but I think that the COSA software model should be supported by every government in the world because it is for the greater good of humanity. This is not the time for one country or corporation to try to gain an unfair advantage in the market through legal or other means.

Fair and sensible standards are one area where governments should be very active, in my opinion. It would be a monumental mistake if different countries and/or companies decided to adopt incompatible standards for the new software model. Standardizing COSA must be an international undertaking preferably done by a single non-profit organization set up or chosen for that purpose. I have already mentioned the Open Group as a possible choice in a previous news item. So what's in it for the government? The answer is that, once COSA is adopted and allowed to flourish, the vastly increased revenue from an expanding global economy will be more than welcome.

What's in it for Me?

Given the dog-eat-dog business climate, it is tempting (and it would have been relatively easy for me) to acquire patent "protection" for every COSA innovation. However, I have always felt that the eventual adoption of the COSA model by the computer community is so critical to the safety and welfare of the public at large that I must oppose any attempt by any organization or individual to seek any sort of intellectual property advantage. There will be plenty of opportunities for everybody.

Although I have known since the first day I sat down to learn assembly language programming (1980) that the computer industry should have adopted a non-algorithmic software model from the beginning, many of the key concepts and principles underlying the COSA model did not crystallize in my mind overnight. It may seem easy after the fact but it took me a long time to expunge all vestiges of the algorithmic mindset out of my system. For example, the connection between reliability and the use of a non-algorithmic model did not  occur to me until much later. What I am driving at is that the hard work has already been done. Now anybody with internet access can download it free of charge. So what's in it for me? When do I get paid?

In a free market economic system, the price of a commodity or service is a value judgment on the part of the buyer. In matters having to do with intellectual labor, I subscribe to an honor system: The buyer should pay the seller whatever he or she thinks the product is worth after using it. In this case, the buyer is society in general and the computer industry in particular. It is up to society to decide whether or not my contribution to software engineering is valuable. If it deems that COSA is worth anything, then I expect payment in return. Otherwise, I expect nothing. Having said that, my biggest reward will be the satisfaction of seeing the COSA model implemented in every computer on the planet.

What's in it for the Investor?

Now is not the time for companies to use intellectual property laws to selfishly block so-called competitors out of the market. There will be plenty of opportunities to go around for everyone. Now is the time for the entire computer community to come together and solve the software reliability crisis once and for all.

I do not hide the fact that I have been looking for a corporate or government sponsor. At the same time, I realize that the intellectual property mindset is so ingrained in our culture that my liberal stance is likely to be detrimental to my goal of securing private funds. That being said, what's in it for the investor? The answer is that the first software company to implement a proprietary COSA system and use it to develop rock-solid solutions for its customers is bound to make a killing in the market. No company can be legally forced to divulge its source code or share its development tools with another. These are trade secrets which are protected by law. Of course, since the COSA model is no secret, others will be free to implement their own proprietary COSA-compliant systems and eventually compete on an equal footing. But it is a fact that being first to market with a revolutionary product or service is always a tremendous advantage.

The initial investment for a COSA development project will be minimal. I estimate that a comprehensive COSA desktop operating system, including all the necessary software construction tools, support for mass storage and networking, and the usual office application suite, will take less than two years to implement. The total cost should be about two million dollars (US), a mere pittance compared to the eventual benefits and the huge sums that have already been wasted. A COSA virtual machine to be used in legacy systems and embedded applications will take a lot less time and money. COSA easily lends itself to different niche markets and business models

 

October 7, 2004

Event Handling, 12:10 AM EST

I have already written at length about the need to resolve data dependencies. Data are the passive objects that comprise the internal environment of a COSA system. Changes in data are internal sensory events that must be communicated to all relevant active objects in a timely manner. As I have shown, data dependencies at the cell level are handled automatically in COSA. This ensures complete coverage of internally triggered events. But changes in data are not the only events that occur in a software system. Events are also triggered by external phenomena such as key presses, mouse movements, I/O interrupts, etc... Oftentimes, new events are generated as a result of a combination of other events (see logic and sequence detectors).

Total Vision

One of the distinguishing characteristics of COSA is that all events, whether external or internal, are treated exactly the same way: they are all sensory signals which must be dealt with and cannot be ignored. In conventional algorithmic software, it is up to the programmer to write code that will call various subroutines to handle the events. If the subroutine is not called (for whatever reason), the event is ignored, which often leads to catastrophic failures. I have taken to calling it the software vision problem.

The reason that this is problematic is that testing for a given change may occur in many places in an algorithmic program. For example, every subroutine that needs to test for a given change in a variable must either provide its own test code in the form of a comparison operation or call another subroutine to perform the test on its behalf. In either case, the test cannot be performed unless the subroutine is called. Furthermore, the correct timing of a test is crucial since the importance of an event is valid only within a limited temporal window.

This problem does not exist in COSA because a COSA program does not depend on function calls. COSA is 100% event-driven. Every action or operation is performed as a result of an event. No exception! The mechanism is such that events cannot be ignored by the objects that need them. The result is what I call total vision, which is probably the most significant factor in ensuring rock-solid reliability in a signal-driven reactive software system.

 

October 2, 2004

Data-centered Software Systems, 8:40 PM EST

Recently, it occurred to me that the COSA operating system belongs to a class of software systems known as "data-centered software systems" although I cannot say that I am enamored with the choice of label. I would much prefer "change-driven software systems." I did a search on Google and came across an article (see below) that, at first glance, seems to understand the correlation between reliability and the need to properly manage data dependencies. The paper explains the importance of keeping relevant components informed of changes in data regardless of what causes the changes or when they occur. Data dependencies are handled automatically in a COSA development environment with the use of "effector-sensor associations" (ESA). COSA goes one step further, however, by enforcing relationships at the elementary object or cell (effector/sensor) level, not just the component level. The result is the complete elimination of blind code. This will, in turn, lead to rock solid reliability.

Improving Software Reliability in Data-centered Software Systems (PDF format)

 

October 1, 2004

The COSA Reliability Principle (CRP), 12:45 PM EST

According to the COSA Reliability Principle or CRP, the robustness of a COSA program is proportional to its complexity. In other words, the higher the complexity, the stronger the reliability. I know it goes against intuition but this is how it works. Check it out.

(12-21-2004) The item above is obsolete. See the new COSA Reliability Principle above.

 

September 30, 2004

The Elimination of Blind Code: Automatically Resolving Dependencies, 12:30 PM EST

Dr. Fred Brooks characterizes conceptual (design) errors as being part of the essence of software. According to Dr. Brooks, one can improve the accidental aspects of software development (programming tools, syntax error detectors, code checkers, etc...), but one can do nothing about the essence. He writes:

"The complexity of software is an essential property, not an accidental one.
[...] From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability.
[...] From complexity of structure comes the difficulty of extending programs to new functions without creating side effects."

Probably the most frequent and hard to eliminate conceptual error is the failure to spot all the hidden dependencies between parts of a program. Unexpected side effects stem from the failure of the programmer to spot one or more dependency between new and old functions (objects) of a program. This is often referred to as the "brittleness of software." Of course, as we know, Dr. Brooks was referring to algorithmic software. But what if we had a non-algorithmic system that automatically resolved all dependencies? The result would be unprecedented reliability.

No More Unforeseen Side Effects

The problem is especially severe when newly hired programmers must maintain and improve legacy systems. A minor change or addition to the system's code is likely to introduce unforeseen side effects. Even the original authors of a program often fail to spot every dependency. They either forget or the code is too complex to manage. The hard reality is that it is almost impossible to identify and resolve all dependencies in complex algorithmic systems. By contrast, it is an easy thing to do if the system employs a signal-based, synchronous software model. Indeed, it can be done automatically by the development environment. See The Cure for Blind Code for more on this.

Embedded Systems Programming

Embedded Systems Programming of CMP Media has posted a short article that I had written in response to one of their feature articles. This has resulted in considerably increased traffic to the Silver Bullet site. Thank you CMP Media. The Silver Bullet message must be made known to as many people in the software development industry as possible. If you value software reliability, help spread the word wherever and whenever you can.

 

September 26, 2004

Software Design vs. Hardware Design, 4:35 PM EST

I added a new paragraph on software design to the Silver Bullet page. The essence of it is that hardware failures are mostly due to physical malfunctions whereas software failures are due to design defects. If we emulate hardware design in software, then software should become just as reliable as hardware.

Jeanne Missed Miami

Hurricane Jeanne went to the north of the Miami area. We had a lot of rain and some wind but nothing major. Miami has been miraculously lucky so far this season. Four hurricanes to hit Florida within the last five weeks and not one of them hit the city directly. Now, we are waiting for that other lady of misery, hurricane Lisa, who is in the Atlantic ocean east of the lesser Antilles.

 

September 24, 2004

Mean Jeanne, 9:55 PM EST

Hurricane Jeanne has already caused a lot of flood damage and killed over two thousand people in Haiti, the Dominican Republic and Puerto Rico. That's when it was only a tropical storm. Now it's a full hurricane and seems to be headed directly toward southern Florida. The forecast is that the eye will land just north of Miami in Broward or Palm Beach counties. Jeanne's winds (about 100 miles or 160 kilometers per hour) are now pounding the northern Bahamas islands, specially Great Abaco, Andros, Grand Bahama and Nassau. Jeanne is not as violent as Ivan the terrible, a category 4 hurricane, but we are expecting a lot of damage from uprooted trees, flying debris (left over from Frances) and flooding. This will be the fourth hurricane to hit Florida in less than two months. An all-time record! Maybe it's time for me to move somewhere else. I'll write a report in a couple of days. In the meantime, you can follow Jeanne's path of destruction at the NOAA site.

 

September 23, 2004

COSA Business Models, 5:00 PM EST

One of the nice things about COSA is that it can accommodate several types of business models that target specific niche markets. Below is a list of products and/or services for which COSA is ideally suited.

Embedded COSA Operating System (ECOS). COSA would be perfect as the basis for a small embedded operating system for mission-critical applications and/or portable devices such as automotive control systems, avionics, cell (mobile) phones, set-top boxes, PDAs, etc...

COSA Virtual Machine (CVM). Similar to the Java Virtual Machine (JVM), the CVM could serve as an application execution engine for use in existing legacy operating systems such as Windows, Linux, OSX, etc... CVM and ECOS would have largely compatible execution kernels. This means that the same software construction tools (see below) could be used to develop applications for both environments.

COSA Development Studio (CDS). The CDS would consist of a set of graphical tools for designing and testing COSA applications. It could be used as a proprietary rapid application development (RAD) tool with which to create software for either CVM, ECOS or COS (see below). CDS could be hosted on any of a number of existing desktop OSs. It could also be sold to the public as a RAD tool for legacy systems (CVM), embedded systems (ECOS) or the COSA operating system (COS).

COSA Operating System (COS). COS could be either an open or closed source OS depending on the business model. It is a full operating system in the sense that it would include all the usual service components and applications found in systems like Linux, MacOS and Windows. In addition, COS would, due to its very nature, automatically support cluster computing for high-performance applications such as weather forecasting and scientific/technical simulations. COS should be initially marketed to businesses and government agencies, especially for mission-critical environments.

COSA-Optimized Processors (COP). These are RISC-like central processing units (CPU) designed and built especially for the COSA software model. COPs would process COSA cells directly and would replace most of the COSA execution kernel. The end result would be extremely fast processing and simulated parallelism implemented at the chip level. COP chips can be designed for various markets such as end-user products (desktop computers, cell (mobile) phones, set top boxes, game boxes, notebook computers, laptops, etc...) and mission-critical business systems.

COSA Neural Processors (CNP). The COSA project was heavily influenced by my ongoing work in spiking (pulsed) neural networks or SNNs. Since COSA cells are similar to spiking neurons, it makes sense to extend the capabilities of COSA-optimized processors so as to add support for fast SNN processing. Neural network driven applications are bound to multiply in the near future. The nice thing about CNPs is that they would be ideal for large-scale distributed SNN applications that require hundreds of millions or even billions of neurons.

 

September 21, 2004

The FAA Is at it Again, 8:45 PM EST

Southern California's air traffic control system broke down last week and nearly caused a major disaster. Although the failure was blamed on human error, the real culprit was the software, a so-called "design glitch." Software complexity and unreliability are the bane of air traffic control and avionics software systems worldwide. As Dr. Fred Brooks pointed out, hard-to-manage complexity is an essential characteristic of software. Algorithmic software, that is. Big software systems are so brittle and unpredictable that any minor modification is likely to cause a catastrophic crash. Many managers are reluctant to fix "minor" annoyances and will try to find solutions around a problem which do not involve programming or code modification. 

A couple of years ago, I approached the FAA and tried to convince them that there is a much better and safer way to program computers by using a non-algorithmic model. They rejected my suggestions out of hand (see the Open Letter to CyLab). In my opinion, this latest incident in Southern California will not be the last. Similar failures will increase in frequency if only because the current aging software system in use at most airports was not designed to handle today's air traffic volume. Sooner of later, a defect due to some modification or addition to the existing software will cause a major disaster.

The Ancient Curse of the Algorithm

In the mid nineties, the FAA blew more than $1.5 billion on a new advanced air traffic control system (the Advanced Automation System or AAS, developed by IBM) that was so riddled with bugs, most of it had to be abandoned. Its replacement (STARS, developed by Raytheon) went through several delays and cost overruns that went from $460 million (original estimate) to $1.4 billion dollars.

Not to be outdone, the British National Air Traffic Control Service (NATS) seems to be having all sorts of problems with its own 940 million Euro system (*) developed by Lockheed Martin, a subsidiary of General Electric. It is interesting to note that several competing companies who do business with the FAA (Boeing, Lockheed and Raytheon) have visited the Silver Bullet site in the last two weeks or so.

These are not isolated cases. History is littered with the remnants of expensive software engineering projects that were started but never deployed due to unreliability problems. The cost to industry and society has been staggering. It is the curse of the algorithm. But all is not lost. It is not too late for the FAA and other aviation agencies around the world to adopt the COSA software model and start saving both money and lives. I just hope they would make up their minds sooner rather than later.

* The Swanwick project was six years late and 180m over budget before going live in January 2002.

Leapfrogging the Competition

How can countries like India, China, Brazil and others come from behind and take the lead in the global computer market? Answer: All they have to do is develop and market operating systems and software construction tools that solve the reliability problem. In addition, they can set up IC manufacturing plants to design and build RISC processors tailored for the new software model. They can take advantage of the complacency and lethargy of the European and North American computer industry by being the first to appear on the market with a revolutionary technology.

International Standards Organization

I personally believe that the reliability of software is so important to world safety and security that it would be best that the initial development of the new technology be conducted under the auspices of an international organization. This body would be given the authority to create and enforce industry-wide standards pertaining to data structures for such things as cells, components and various low-level messages needed for a bare-bone operating system. One of the things that must be standardized early on is the assignment of unique message identification numbers for operating system-specific components. Actual implementation of the OS kernel, software development tools and optimized processors would be left to private industry. In my opinion, there is no need to form a new standards organization. The Open Group is perfect as it is.

 

September 20, 2004

The Sustainable Careers Consortium (SCC), 11:40 AM EST

CyLab is the Carnegie Mellon group in charge of the Sustainable Computing Consortium (SCC). The SCC was founded by NASA (who, it seems, provided most of the initial funding), CMU and several industry organizations with the expressed goal of improving software reliability and safety. I've done a little research and it is now clear to me that the folks at CyLab and the SCC are not interested in finding a solution to the software problem. One of the members of the SCC is none other than Cigital, a software reliability firm who is on the record for insisting that there is no silver bullet that will solve the crisis. Having companies like Cigital on board is like putting the foxes in charge of the chicken coop, in my opinion. Why? Simply because a final solution to the problem will put them out of business. This may not be a politically correct thing to say in some circles, but it is the truth.

About a couple of weeks ago, shortly after I posted the Open Letter to CyLab, the Silver Bullet site was accessed by several computers at CyLab. They downloaded every page (yes, I do monitor web traffic on the Silver Bullet pages) having to do with Project COSA. Not a peep out of CyLab since. This is not surprising in the least. What follows is a quote taken from an article titled "Making software NASA-tough" by Brian Robinson for the magazine Federal Computer Week:

"The SCC is not about developing a magical technology bullet, but rather to understand this issue as a market phenomenon and to try and move it along."

This is according to William Scherlis, co-director of the SCC and principal research scientist at Carnegie Mellon's School of Computer Science. Isn't it amazing that a professor of computer science at CMU would have no compunction in characterizing a purely technological problem as a market phenomenon? Admittedly the article appeared in July 2002, but the point here is that this was their position from the beginning. Denying the possibility of developing a silver bullet and calling it a "magical technology bullet" is a way of saying, "we are going to work on it, but don't bother hoping for a solution. Just keep the money flowing in and all will be well with the world." Needless to say, most of it is the taxpayer's money. In the meantime, software glitches and low productivity are costing the world many billions of dollars a year in delays and lost revenue.

The SCC is two years old. Has it made any progress toward solving the software crisis since it was formed? I don't think so. How much longer can this go on?

 

September 14, 2004

Computer Geeks: the Neo-Luddites?, 9:25 PM EST

In early nineteenth century England, at the dawn of the industrial revolution, an organized worker movement known as the Luddites (after Ned Ludd) revolted against what they considered to be a threat to their livelihood. They violently opposed the introduction of mechanized automated looms by smashing them with hammers. History tells us that the Luddites were no match against the rich and powerful industrialists. The movement was brutally squashed and many of its leaders were publicly hanged or forcibly deported.

One would expect that the average computer scientist or programmer would welcome any solution to the software reliability crisis with open arms. After all, they are the ones who have to deal with the bugs in their programs. It turns out that this is not the case. I get more blatant, in-your-face, hostility from software engineers and computer scientists than from any other sector of the computer business.

I had thought about it before but I never really tried to understand why something as easy to grasp as the COSA model should encounter so much resistance from the software development community. COSA is not, after all, rocket science. It occurred to me today (something happened which I am not at liberty to divulge) that any solution to the software reliability crisis is a major threat to the livelihood of programmers and software experts worldwide. Why? For two reasons a) Programmers spend the major part of their working hours, not writing code, but debugging it; and b) There is a huge software reliability industry out there whose continued prosperity depends on the sustained unreliability of software. Just do a search on Google for "software reliability" or "software quality assurance" to get an idea of how vast this industry has become.

It is obvious that unreliable software is keeping a lot of people gainfully employed. I am very well aware of the fact that the adoption of the COSA model by the industry is going to displace a lot of well-paying jobs. Am I fighting a losing battle? Maybe. Should I feel guilty? I don't think so. It is not my fault that our economic systems are based on human labor. And besides, nobody can stop the march of progress. What will happen when advanced robots and artificial intelligences replace everybody, i.e., when human labor and expertise become obsolete? I shudder at the thought. This is the world that we live in. An interesting world, to say the least.

 

September 13, 2004

Intel vs. AMD, 10:25 PM EST

Most of us are aware of the intense competition between Intel and Advance Micro Devices in the CPU marketplace. While Intel has about 82% of the total US market share, AMD recently outsold Intel in the retail desktop market 54% to 45%. They are giving Intel a run for their money, which is a good thing for consumers. It is becoming harder and harder to compete in this business by cranking up processing speed. Manufacturers need to find other ways to get an edge.

What would happen if a new computing paradigm appeared on the scene and rapidly displaced the old one? Of course, I'm thinking of the COSA model here (what else?), but what if this new computing model could be significantly enhanced by specially designed chip sets? Well, it goes without saying that the first chip manufacturer to release these chips would make a killing. Are the marketers and trend prognosticators at AMD and Intel savvy enough to anticipate when the computing world is going to change course? Maybe.

So far, AMD is having a hard time penetrating the commercial and notebook marketplace where Intel is the undisputed heavyweight champion. AMD is not even a contender yet. Will AMD see the writing on the wall? Do they have enough understanding of the market forces to perceive that the biggest problem in the computer industry is software reliability? Are they wise enough to foresee that any solution to this problem would drastically transform the market landscape, not only for software but for CPUs as well?

In order to tackle the new software model, the new CPUs must be designed to "understand" such new concepts as synapses, signal source and destination, and input and output processing lists. CPUs should no longer be seen as instruction processors but as cell processors. It is a radical new way of looking at things. Of course, one would be foolish to release a new CPU unless the specifications for the new operating system are stable enough. Fortunately, the COSA kernel is simple enough that it should not take long for it to stabilize.

There is no question about it, in my opinion: The non-algorithmic synchronous software model (the COSA model) will sooner or later replace the old system, for the simple reason that it will solve the reliability problem. If AMD wants to get a long-term foothold in this industry, I suggest that they start thinking about COSA right away and beat Intel to the market with a killer product. It's probably their only chance.

But then again, why does it have to be either AMD or Intel? Why can't it be a new contender? Why can't it be Motorola, or Transmeta, or Texas Instruments, or Sun Microsystems? And why can't it be the Japanese, or the Taiwanese, or the Brazilians, or the Finns, or some other country? And let us not forget mainland China. We'll just have to wait and see. There is a sweet smell of revolution in the air.

 

September 12, 2004

Silver Bullet Discussion Group, 12:25 PM EST

Here are some articles I recently posted on the Silver Bullet discussion group. Join the group to participate.

 

September 10, 2004

NASA's History of Software Failures, 1:25 PM EST

NASA's chronic string of catastrophic failures would be laughable if it weren't so tragic. Most of the failures were due to defects in their software. Just recently, NASA's 250+ million dollar Genesis probe crashed in the desert. None of the probe's chutes deployed as planned. Barring a physical malfunction, the reason will most likely be attributed to some sort of software failure, although an investigation to determine the cause of this latest accident is under way.

Alright, I agree that this is unfair to NASA since they've had some spectacular successes as well. It's just that some of the failures are almost unforgivable. I'm thinking of the 125 million dollar Mars Climate Orbiter that was lost because one part of the software was "thinking" in metric units while the other was using English units (inches, feet and pounds). Had NASA and its hired consultants been using a software construction and execution environment based on the COSA model, none of these "software accidents" would have happened.

A little over two years ago, I contacted several people at NASA to try to get them interested in my ideas on software reliability. The following is a list of the people I sent emails to.

Dr. Linda Rosenberg
Software Assurance Technology Office
Email: Linda.Rosenberg@gsfc.nasa.gov

"Dr. Linda H. Rosenberg serves as the Chief Scientist for Software Assurance for Goddard Space Flight Center (GSFC), NASA in the Office of Systems Safety and Mission Assurance Directorate and is the former division chief of the Software Assurance Technology Office (SATO). Dr. Rosenberg is a recognized International expert in the areas of software assurance, software metrics, requirements and reliability."

The following is quoted from a paper she authored in 1998 (emphasis added):

"[Software objects] are often heralded as the silver bullet for solving software problems, while in reality there is no silver bullet; object oriented development has proved its value for systems that must be maintained and modified.

Dr. Rosenberg is clearly in the no-silver-bullet camp. She may have changed her mind since the paper was published but I doubt it. Unbeknownst to Dr. Rosenberg, there are two types of software objects, the conventional algorithmic kind and the synchronous kind. In her paper, she is obviously referring to the former and, as such, her no-silver-bullet stance is understandable. Hopefully for NASA's sake, one day soon, she'll come to realize that she has not been looking at the whole picture.

Michael Mewhinney
NASA Ames Research Center
E-mail: Michael.Mewhinney@nasa.gov

Dr. Michael Lowry
NASA Ames Research Center
Email: lowry@ptolemy.arc.nasa.gov

Not one of the individuals listed above bothered to reply to my emails. That is rather rude, wouldn't you say? Now, I know that NASA has forked more than 23 million dollars of the tax payer's money over to Carnegie Mellon's CyLab in support of the Sustainable Computing Consortium (SCC). Will that money be wasted (it's been close to two years already) or will Dr. William Guttman, the SCC's director at CyLab come to his senses and do the right thing?

 

September 9, 2004

Open Letter to CyLab, 12:35 PM EST

I slightly modified the open letter to CyLab: I added a link to the FAA and Dr. Dan Mehan's email address. Please do your part and write to the FAA, NASA, DARPA, CyLab (and anyone else who might be interested in robust software around the world) and ask them to take a look at the Silver Bullet article and at Project COSA. There is no doubt in my mind that these ideas will solve the global software reliability crisis.

This is extremely important, not only for the economic health of the software industry and its customers, but for general public safety as well. Indeed, I foresee that COSA will trigger a renaissance of the software industry. Even IC/CPU manufacturers such as Intel, AMD, Transmetta and Motorola wil benefit immensely because they can make new state-of-the-art processors specially designed for the COSA software model.

The Silver Bullet site has been getting a lot of hits lately, especially from companies like Boeing, LM Ericsson and several financial and educational institutions from around the world, organizations for whom software defects are no laughing matter. When this whole thing explodes (and it will, sooner or later), the FAA's incompetence will be there for everyone to see. They had the solution in their lap many years ago and they dismissed it. In a rather uncourteous (they stopped replying to my emails) manner, I might add. They should have known better, given the critical nature of aviation and avionics software. But it is never too late. Let us hope they see the light.

 

September 4, 2004

Open Letter to CyLab, 2:15 PM EST

CyLab is a project hosted by Carnegie Mellon University in Pennsylvania. Its primary goal is to find better ways to develop dependable and secure computing, i.e., to find a viable solution to the software reliability crisis. CyLab is supported by the U.S. federal government and by various international corporations. Due to the serious nature of the reliability crisis, these companies decided to form what is known as the Sustainable Computing Consortium. The SCC is run by CyLab under the direction of Bill Guttman. Dr. Guttman is in a privileged and fortunate position to make a fateful decision regarding software reliability, a decision which will affect the future of the entire software industry. I direct this open letter to Dr. Guttman.

 

September 2, 2004

Hurricane Frances, 12:25 PM EST

I live in southern Florida and I am now getting ready for Hurricane Frances which is now over the Bahamas. I have experienced a category 4 hurricane many years ago in the eastern Caribbean and I know how dangerous it can be. If I'm still around after the hurricane, I'll write a report.

 

September 1, 2004

Closing Down, 10:30 AM EST

Ok. For something completely different. A lot of people have benefited freely from the information contained on this site. If it were completely up to me, I would continue to provide this information free of charge. But I can no longer afford it. Unless I get a source of funding in the next few days, I will be forced to close down the site. So I suggest that everyone copy the latest pages to your computers. Sorry.

Von Neumann Architectures

In response to criticism from a few readers, I added a new section on Von Neumann architectures to the Silver Bullet page.

 

 

2004-2006 Louis Savain

Copy and distribute freely