Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

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 of.

• confusing the intention with the implementation. Software 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.