How do you solve a software engineering problem when there are too many sub

Publié le par ccaryjbaxtert14

But what to do when there are too many problems? In the ancient Greek mythology is a monster Hydra. Hydra has ten heads. The worst thing is, however, that if one head is destroyed, ten new ones will appear. A familiar situation? When one problem is solved, ten others will appear.


There are two classes of problems:


*Problems independent from each other


*Problems coupled with each other


Let´s first consider problems independent from each other. For example, a person has many different hobbies, and not enough time for all of them.


General solution is rather simple: Select the most important problem, solve others later, or ignore them at all. If a person likes hunting, opera, travel and writing poems, and hasn´t enough time for all these activities, he/she can choose for example hunting and reject all others.


Unfortunately, usually the situation is not that simple. Usually problems are coupled with each other. For example, many problems in an industrial enterprise are coupled: quality, cost-efficiency, time-to-market, satisfying the needs of the customer. Technical features of machinery are often interdependent, too. We cannot decide that this year we´ll accentuate cost-efficiency and will not care so much of quality. We cannot say that it is important to decrease time-to-market, and improving service is less important. Or the designer cannot decide that it is necessary to increase productivity, and safety is the feature of second priority. We usually have many problems, all equally important, and all urgent go kart parts cheap.


The general solution is to find a single, common cause of the complex of problems and solve it. If you have ten problems, don't try to solve all of them. It may be, that all the ten problems are impossible to solve, and one must find the eleventh problem. The solution of the eleventh problem makes it possible to solve ten others.


If we consider famous successes and failures in the history of industry, we can easily see how this rule works. The mountain bike was an innovative concept which created a new market for new quality with both low cost and high cost options. The failure of the plastic bike Itera shows that if the initial concept lacks innovation, even heavy efforts in next stages of development are useless.


Windows has been so successful as a computer interface due to the basic concept: a user-friendly interface (invented by Xerox, later popularised by Apple) is combined with widely accepted industrial standards (IBM compatible computers). The problems of Apple are caused by the limits of concept, which has been user-friendly, but not compatible.


The conclusion: If the initial concept doesn't clearly display the contradiction which is solved, and the new quality which will be created, this concept will most probably fail. The idea of Itera was to make a bicycle from plastic. "Plastic" of different polymer materials have served successfully as "contradiction solvers" in many innovations. For example a Finnish company Fiskars made the handle of an axe from plastic, instead of wood. A plastic handle doesn't need repairs - a benefit easy to see. Further - it became possible to make a handle hollow. The axe became lighter. In addition, the center of gravity moved nearer to the head, which gave a more powerful strike. The contradictions were solved: repair-free tool without extra cost, more striking force without extra weight. In the Itera concept of the 1970s the new material became an end in itself and didn't solve any contradiction. Customers couldn't see benefits compared with a traditional bike made from steel.


More article about it:

Commenter cet article