Prev: ABSOFT FORTRAN v10 COMPILER
Next: variable case expressions??
From: Gary Scott on 22 Oct 2006 18:41
beliavsky(a)aol.com wrote:
> Gary Scott wrote:
>
> <snip>
>
>>What I have trouble with relates to the following situation. During a
>>"Value Stream" process assessment this week, I kept hearing "software
>>types" making statements along the lines of "once you've tested it the
>>first time, you don't have to include this system function in your
>>regression planning because it is "object oriented"".
>>
>>I've been testing systems developed using "procedural" software
>>development methods (Jovial, C, Ada) for ~25 years and I've been testing
>>other systems developed using "object oriented" methods (Ada, later C++)
>>for ~10 years. I've found the following: 1) there is no evidence of
>>any reduction in the need to perform regression testing in the object
>>oriented configurations (corrections to one function breaks supposedly
>>unrelated functions at about the same rate as occurred in the
>>procedurally developed configurations). 2) when anomalies ARE
>>discovered, they are MUCH more difficult to analyze and correct in the
>>object oriented configurations.
>
>
> Les Hatton has studied the correctness of scientific computing codes
> extensively. In his report "Dross ex machina: A long hard look at the
> influenceof software defects in computer modelling" he writes on p38 of
> the pdf file at http://www.leshatton.org/Documents/dross_2006.pdf
>
> "C++ OO systems have comparable defect densities to conventional C or
> Pascal systems.
>
> Each defect in a C++ OO system takes about twice as long to fix as in a
> conventional system. This is true for both simple defects AND difficult
> ones. The whole distribution is right shifted.
>
> Components using inheritance have been observed to have 6 times the
> defect density.
>
> How much of this is attributable to C++ is unknown."
>
> In sumarizing the 1998 paper
> "Does OO sync with the way we think?" IEEE Software, 15(3), p.46-54 ,
> available at http://www.leshatton.org/Documents/OO_IS698.pdf , Hatton
> writes as follows:
>
> "This paper argues from substantial real data that OO based systems
> written in C++ appear to increase the cost of fixing defects
> significantly when compared with systems written in either C or
> Pascal. The fact that C++ is built on C suggests that the OO features
> themselves are at least partly responsible rather than simply blaming
> it on C++. As a result, it goes on to suggest that at least some
> aspects of OO, for example inheritance, which appears to be a defect
> attractor, is an unsafe mechanism in terms of how we think about
> software systems. It certainly would not come as a surprise to any
> geneticist that we can inherit mistakes.
>
> I should note that this paper had an unusually turbulent review period
> because it criticised OO. 2 reviewers said they would cut their
> throats if it was published and 3 said the opposite. The paper was
> only published on condition that the OO community could publish a
> rebuttal. I found this very amusing as my paper contains significant
> data. The rebuttal had none. This sort of thing is normal in software
> engineering which mostly operates in a measurement-free zone. I even
> had one particular OO supporter claim that my experiments were
> 'uncontrolled' in spite of the fact that a) the details were all
> published and b) they had never done any. Ultimately we all lose by
> this level of ignorance and I do wish we would rely more on trying to
> nail down important facets of software development and not just talk
> unquantifiable bollocks all the time. but maybe I'm being too
> idealistic."
>
Most of my "data" is anecdotal, but it completely agrees with the above.
Since we're continously adding new, never before seen stuff, the fact
that preexisting functions developed using OO techniques still work has
not been of much real advantage as they continued to work when it was
developed using "procedural" techniques as well. The original
development of these new capabilities costs more and takes longer than
an equivalent capability under the older techniques, so it is hard to
see where the advantages are. I believe reliability, cost, and schedule
and the ability to "integrate" the system would be improved if we backed
off of the OO methodology, else determine why it has not been the
advertised panacea.

--

Gary Scott
mailto:garylscott(a)sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford
 | 
Pages: 1
Prev: ABSOFT FORTRAN v10 COMPILER
Next: variable case expressions??