Would you like to make this site your homepage? It's fast and easy...
Yes, Please make this my home page!
If you would like to send in your
comments or to contribute your material to these pages, please send your
mail to: Alex Bunard. I will
try and post your contribution within seven days from the time I receive
To download my latest presentation
on Java (held on November 18, 1999 for the Vancouver
Java Users Group), click on this link:
Object Oriented Vs. Component Based Development In
Java (154,643 Bytes in size,
PowerPoint 97 file format)
One of the biggest disappointments in the
world of technology is the overall under achievement of the discipline
of software engineering. While it is true that software is one of
the youngest engineering disciplines (it is still in its early developmental
stages), one would expect that its overwhelming rate of penetration in
every pore of modern society should have precipitated significantly higher
level of quality. There seem to be several reasons why software products
today, in general, are barely usable:
the whole area is grossly mystified.
In the early days of software engineering (back in the sixties, seventies
and eighties), computer programming was an arcane discipline reserved only
for the initiated gurus. Non-initiated people felt generally intimidated
by the lack of immediate ways of comprehending the computer programs' esoteric
code. A good number of people were afraid to even sit at a computer terminal,
thinking that somehow such an exercise will turn into some sort of an IQ
test, and that they would be "defeated" by the machine.
the everyday usage of computers was largely
popularized by the marketing work accomplished by the Microsoft Corp..
During the early nineties, Microsoft launched a humongous campaign with
the intention to educate the population and to create vast new markets
that will consume their desktop-centric products. This "project demystification"
worked amazingly well. Many people joined the ranks of computer users thanks
to the Microsoft's brand of graphical user interface (a.k.a. "Windows")
which served a role of making the so-called "human/machine barrier" look
less intimidating. However, it turned out that Microsoft has done a half-baked
job: while they've succeeded, beyond expectation, in penetrating the markets,
the hastily cobbled applications that were barely functioning served a
non-honorable function of conditioning the masses to accept lousy products
as the everyday norm.
to this very day, software development
is a discipline ruled by the formally trained computer programmers.
These experts understand how computers work inside-out, but they generally
don't seem to understand how people work. Consequently, the behavior of
a typical software application reveals a lot about the internals of a computer,
but that's not something anyone would be interested to know in the first
place. People wish to use the software products in order to make their
jobs easier and in order to accomplish more than is possible without the
aide of software; people couldn't care less about the internal architecture
that's necessary for the operations to be carried out (similar to the fact
that people don't really care how their cars are internally functioning
so long as they take them from A to B, comfortably). This is the point
of contention that typical software developers seem to be blissfully unaware
confusing the intention with the
development is a discipline that aims at solving certain class of problems
for humans. It is not merely a game; it must demonstrate that it can deliver
something useful, with a certain level of consistency. In this light, people
use software products in order to increase their productivity and their
efficiency. Typically, a software development cycle starts with identifying
the problem (for example, the problem that a business is faced with could
be "the need for a more efficient message delivery"). Next, people express
their intentions, i.e. "it is our intention to use software products
to enhance the efficiency of the message delivery within our company as
well as outside our company". Only when these two phases have been completed
do we start looking at the implementation of the software product.
However, this is exactly where the problem begins: when the developers
are brought into the picture, they immediately subject the clearly defined
intentions to the murky and muddled implementation issues. For
instance, they would typically remark: "yeah, we understand what you are
trying to accomplish with your project, but because we are running such-and-such
an operating system with such-and-such a networking protocol, it simply
is not doable!" These two areas (intention and implementation)
must be kept clearly separated. The implementation of a solution must be
at all times kept as a secondary issue, while the intention must always
be given the full precedence.
Sorry, the remaining
material for this page is still under construction
All original material in these
web pages copyright © Alex Bunard.