[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

John Buehler wrote:

> The stability of a domain is absolutely an important part of
> creating quality software.  This is true whether you're using
> components or not.  Stability implies time, and time permits
> understanding.  Lack of comprehension is the number one reason that
> we have bugs (my own assertion).  Precise contracts are a claim that
> both sides of a contractual interaction can know very specific
> things about what's going to happen during that interaction.

One may question if a zillion contracts written in OCL, and which most
likely contain "bugs" themselves, are going to be very helpful in a
system that should evolve to meet changing requirements.  Maybe it is
better to have a good abstract model which supports the intuitive
understanding the designers have of the domain. (OO) I believe that
light methods like extremeprogramming is one step in the right
direction for evolutionary projects. Now you even get editors that
will abstract your source code into visual models. Better tools and
extreme programming could become practical.

> problem solving.  If standards had never evolved, we'd still be
> writing assembly code and building applications no more complex than
> a clock.

This is another issue/level, which does not model the domain.

> And this echoes the sentiments of the vast majority of the software
> development community.  Taking the time to come up with precise
> contracts takes too long, so we crank out code at a furious rate.
> And that code is buggy.  But not buggy enough to annoy consumers.

You don't need component-thinking to do separate testing of modules
(units). Or to use invariants etc.

> There is nothing inherent in components that produces a performance
> penalty.  Further, the inflexibility that you're referring to is the
> same inflexibility that comes from having to use standardized parts
> in any construction process.  Note that you're using standard
> network protocols, standard schedulers, standard file systems, etc.

Again this is irrelevant, and does not concern how you model the
domain.  You are avoiding the problem which is indeed about
dependencies within the model.

> and our compilers help us to sort that out.  But changing the
> behavior of a piece of software without informing the software that
> uses it is not something that current tools support - yet such
> things can be lethal on a non-trivial project.

This is a tools discussion and not about wrapping up modules in a
facade with a minimum of interdependencies and designing by
specification.  It is quite possible that you have better tools for
componentbased designs.

--
Ola  -  http://www.notam.uio.no/~olagr/

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev