So what is the error? It is a reuse error. The SRI horizontal bias module was reused from a 10-year-old software, the software from Ariane 4. But this is not the full story: It is a reuse specification error
Scary ! [ July 26, 2003: Message edited by: HS Thomas ]
DBC is an interesting tool. There are some implementations for Java: http://www.google.com/search?q=%22design+by+contract%22+java - don't know about Eclipse plugins though (it doesn't have anything to do with refactoring). I don't think that DBC would have saved the Ariane, though. The problem was that the components never had been tested in concert under the new conditions, so the DBC-assertions also would have only been failed during the start - probably to the same effect as the exception. As so often, the main problem probably wasn't technical in nature, but cultural - there was lack of collaboration between the different contractors. See http://www.flash.net/~kennieg/ariane.html for a more detailed analysis.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: May 15, 2002
I thought there might be some link between Design By Contract (pre-conditions, assertions, post-conditions) and Test Driven Development but I have yet to spot. (Not surprising considering I don't know either). Here is another tale of the Sins of Omission .
EDITORIAL Sins of Omission
In ice hockey when a player scores three goals it is called a hat trick. In CHAOS 2002 we saw Ellen Hancock score a hat trick with her third CHAOS talk entitled �Sins of Omission.� Sins of omission are things that cause projects to fail because they were not brought to light and dealt a solution. Ellen cited three things she thought were important to achieve a successful outcome: 1) strategic decisions should have extensive review within the corporation; 2) projects must have internal buy-in and should be market driven; and 3) feature options should be clarified and approved by the users. Failures in these areas tend not to be deliberate decisions but rather unintended omissions in execution. IBM CICS S/390 product generates close to a billion dollars per year for IBM. It is one of the most successful software products of all time. In the late 80s and early 90s, IBM was interested in expanding the CICS market reach into UNIX, and later NT. So in 1991, IBM began a project to create a UNIX version of CICS to be named CICS/6000. IBM Executive Management made a strategic decision to implement any new product over System Network Architecture. The �Sin of Omission� was the project team did not get the message and made a decision to build the new CICS on top of the Distributed Computing Environment (DCE). Management did not learn of this decision until the product was developed and launched into the marketplace. CICS/6000 was, and still is today, one of IBM�s poorest performing products. Apple had worked for years on a new operating system code named Coppeland. The �Sins of Omission� were many; for example, there were no plan reviews, no statistics on code, testing and functions. Completion dates were determined by marketing without development input. The entire project was done tops down rather than with engineer buy-in. Even if the new operating system were completed, it would not meet customers� needs and had less functionality than the current system, which was stable. Soon after Ellen went to Apple she terminated the Coppeland operating system project. However, the same team was able to successfully revitalize the current system until a new operating system was launched using the Next OS. Early in 1999, through rapid growth, Exodus Communication went past the capabilities of its then current IT structure. A management decision was made to install SIEBEL for both sales and service support. Input was solicited throughout the organization. Many functions and departments in the company became creative on what functionality was needed. No one could agree on what should be implemented, and when. Because of these back and forth changes, the project experienced numerous delays and restarts. The �Sins of Omission� were the lack of planning and leadership. Finally an executive team was formed to decide what and when the most important features would be implemented. The system was implemented by a series of small releases and became functional in a rapid timeframe. Of course, one can not write about Ellen Hancock and not mention Exodus bankruptcy. As President of Exodus she was the �Queen� of the dotcoms, but that changed rapidly. The tremendous demand, which was initially triggered by start-ups that either failed or could not get additional funding (especially dot-coms), soon evaporated. Enterprise companies became more cautious with IT spending. The rules changed over night. Merrill-Lynch, Goldman Sachs, CSFirst Boston, and many other of the top financial institutions, which just a few months earlier were literally throwing money at her, would no longer take her calls. Shortly after she was fired from Exodus, we asked her what she would have done differently. At that time she mentioned many things. However at CHAOS University, after thinking about it for a few months, she said she would do nothing different. There was nothing she could do. If she did not take the money and expand the business the board would have fired her for being too conservative. Sometimes you are �dammed if you do and dammed it you don�t.� Occasionally projects are like that too.
Originally posted by HS Thomas: I thought there might be some link between Design By Contract (pre-conditions, assertions, post-conditions) and Test Driven Development but I have yet to spot.
TDD and DBC have in common that they both try to document - and to some extent enforce - how the code should be used and what behaviour to expect. They are different in how they try to do this. DBC is internal to the production code, whereas unit tests are external. The former has the advantage that it also works while in production. Of course you'd want to find problems *before* production, so you still need to try some test scenarios - unit tests. So DBC doesn't really reduce the need to unit test (though to some extent unit testing seems to reduce the need for DBC). To me, they also *feel* very different. When doing TDD, virtually every test I add increases the usefulness of a class. Adding a DBC style pre-condition, on the other hand, decreases the classes usefulness. So to me TDD feels more constructive, DBC more destructive.