What exactly is Reusable Software?
if and only if the chance is high that
systems specified and implemented a f t e r P became available will contain P as a building block.
Preconditions for this are:
- It must be easy to learn about the existence and availability of P.
- The effect of calling an interface of P must be well documented in every aspect,
- especially with respect to all the preconditions that need to be satisfied when using P
and all exception that may occur.
Experience is telling us:
does not respect enough these three requirements.
Some reasons for this fact are discussed e.g. in Whatever Happened to Reuse?.
Shortly after the object-oriented programming paradigm was invented, many software engineers argued that object-oriented software — classes — would be reusable automatically. This however was too naiv a view because it ignored the fact that classes poorly documented (or not documented at all) cannot be called reusable.
We learned: Software written in C++ was nearly as hard to understand as software written in C or COBOL.
In practice, reusable software is always a library
- either coming with the compiler for a specific programming language (i.e. as a standard library)
- or as a set of libraries extending the standard library to have a platform for quite a large class of applications (such as, e.g. the JEE classes).
This is so because design and implementation of software for reuse ist much more costly than to create it for use in one specific application only. In 1999 Steve Adolph wrote: A reusable component can cost three to five times more to develop than conventional software; this is so because the reusable component cannot make simplifying assumptions about its environment. Adding to the cost is that we have to document it better and have to test it much more carefully.
The break through for reusable software came with Java and the Javadoc standard. The problem here was that soon too many competing class libraries came to the market (especially as Open Source) and were heavily in use long before revised versions of such functionality could be integrated in the Java Enterprise Edition (i.e. the JEE libraries, which is main stream).
More perfect is Microsoft's .NET approach which guarantees that all reusable .NET software is part of one large class library existing in versions which are guaranteed to be upward compatible and are maintained by one authority only (Microsoft).
Since we have JEE and .NET it makes sense to say:
Microsoft .NET (Mono on Unix) or Oracle JEE
In any other case let it better be called Open Source or Freeware. As such it might or might not become a candidate (or blueprint) for truly reusable software.
Quite an important exception from this simple scenario is the Unix operating system, more precisely: its reimplementation in form of Linux.
Another exception, so you may think, is Apache software in general (Linux is part of it).
So the three big Software Ecosystems — Apache (especially Linux), Java, and .NET — together with the fact that not even IBM software can compete with them seem to prove that software beyond a certain complexity level can, in the long run, be maintained sucessfully only by a VERY LARGE community of developers, many — but certainly not all of them — contributing for free.
On the other hand, it is equally clear, that totally new ideas usually do not come from the inside of these communities. True innovation emerges from some few heads only, may grow in form of nice products that will be "in" for a certain time, but will then either vanish or become part of an ecosystem maintained by a very large, worldwide operating community. In this form only software can be reusable in the best sense of the word, i.e. without leading us to a dead end (a cul de suc).
tags: stw4098NETJEEE: NETngegreit JEEngegreit Ecosystemsngegreit