« Home | PInvoke and IJW » | DBMS Blogs Moved » 

Tuesday, January 24, 2006 

New Methodolgy for Explaining Software Engineering

Software engineering is a delicate science that is difficult to fully understand and hold. Programming is generally a difficult science, which sometimes cannot be understood or mastered by people who are considered smart on the general measures. Bill Gates says that any programmer who will ever be good will be good in few years. After that, whether the programmer is good or not is cast in concrete. But software engineering is more difficult to master even for good programmers, and more over, it is difficult to measure the level of understanding of software engineering students and their ability to apply for what they have learnt in the practical software projects.

One of the noted phenomena in software engineering is that known problems are always repeated, even if the project manager or the development team has read about these problems and their solutions in before.
One of the most famous software engineering books, "the Mythic Man Month is known as the software engineering bible. Although the book is relatively old, the problems in this book are repeated always in software development project. Fred Brooks, the author of the book, comments on this phenomenon with a sense of humor saying "That's why they call it software engineering bible, because every body reads it and no one applies what is found in it".

Here I propose a new methodology for explaining software engineering that I think can increase the level of understanding of software engineering.

Difficulty of understanding and applying software engineering:

Software engineering has two points of difficulty:
  1. Software engineering is a heuristic science. A heuristic science is the science that does not give you solutions to your problems; it just gives you ways in which you can walk to solve this problem. Other examples for heuristic sciences are psychology and architectural design.

    There's one common characteristic shared between heuristic sciences: they all accept innovation more than other sciences. In fact, they need some sort of innovation when applying them.
  2. The natural method of thinking makes software engineering is difficult to understand and apply correctly. To understand this, we have to take a look at who the human mind works.

The Human Mind's Boxing:

The human mind has a natural strong ability for pattern recognition and applying previously know solutions, a mechanism that is called boxing.
The human mind tends to search for characterizing attributes for situations and problems. It has metaphoric boxes each with a name of situation or problem on it. When attributes of a specific situation or problem is recognized, the situation or problem is put into the metaphoric box in mind that has the name of this problem. Once the problem or situation is boxed inside a specific box, the human mind deals with the situation depending on its previous knowledge about this problem or situation.

A perfect situation for using boxing is solving mathematical equations. First the mind tries to classify the equation inside one big box. If the equation contains differentiation symbols, then the problem is put inside the box that has the words differential equations on it. Here the differentiation symbols are the attributes of the problem.
Further boxing can be done, for example to find the degree and order of the equation. For example if the equation was a second order second degree problem, then it is boxed inside a smaller box that has the words second order second degree. After that, the mind applies previously known methods of solving second order second degree differential equations.

This default natural mechanism cannot be used in software engineering. Actually it is the way in which software engineering is written in books or explained in classes that makes it difficult to use boxing with software engineering.

Boxing and Software Engineering:

The default natural boxing mechanism cannot be used in software engineering. Actually it is the way in which software engineering is written in books or explained in classes that makes it difficult to use boxing with software engineering.

Most software engineering books and publications do three mistakes:
  1. They Mention problems without clearly identifying them. What are the Symptoms of this problem? What are the causes of this problem? Etc.This makes it difficult for the software engineer use the natural boxing mechanism to detect problems or wrong development models at early stages of the development cycle.
  2. They mention development models and procedures (for example water fall model) without clearly mentioning what problems this solution or set of procedures addresses. This also can decrease the ability of software engineers to use the natural boxing mechanism to select the appropriate solution or development model when identifying problems in their software development lifecycle.
  3. They mention solutions and software development models without explaining how these models or solutions try to solve a given problem. This can decrease the ability to decrease the ability of software engineers to evaluate a given model and compare it with other models. This can even decrease the ability to create new solutions or modify an old one to fit a given situation. There's no panacea, and every solution for a problem is only a possible solution, not the only one.

How to improve the level of understanding of software engineering?

Software engineering writers and teachers should take care of three points:

  1. Problems should be definitely explained. The attributes or symptoms of each problem should be stated precisely.
  2. When explaining development models, the problems which this development model addresses should be clearly mentioned.
  3. It should be mentioned how every development model tries to solve given problems, with a focusing on the idea that this is a possible solution, not a panacea. This solution or model can be modified or replaced by a better one to fit a given situation.

Nice article.

Since when did you start proposing new methodologies? :)

Post a Comment

Links to this post

Create a Link

About me

  • I'm Mohammad Adel
  • From Cairo, Egypt
  • I am an Eyptian developer @ optimize software company.
My profile