The inefficiency of the software industry
Human beings' first option for solving their problems is turning to brute force. If they fail to do something with certain resources, they end up adding more of them in order to succeed and, only after failing once again, does it occur to them to change methods and paradigms. This is what the systems development industry has traditionally done throughout the world.
There is great inefficiency in manual programming all over the world, and the relative inefficiency is becoming greater as we speak. One can think that with the new languages -for instance, Java or C# instead of using Cobol- there is a 50% to 100% productivity increase over the 1990 standards. But the current applications are much more complex than the 1990 ones (probably 100% more complex). This means that if in the past we were doing badly, nowadays we are actually doing worse. The Y2K syndrome has pushed the carefree use of brute force resources even further.
The response to inefficiency in manual development
Hiring packages: hiring ready-made solutions, knowing that it will only meet a percentage of my requirements, knowing that I will lose individuality, and sometimes, my differentiating advantages. I sacrifice all that and I enter into a general solution. This has been a very considerable trend. Amazingly, great package leaders have managed to turn their weakness into their strength by successfully boasting that if I want my company to be a world-class business I have to use their software (and, obviously, adapt to it).
Import of human resources. This is very clear in Germany, for instance.
Hiring programming and, if possibly, development and even outsourcing in countries with low salaries and good technical capacity. A clear example is the India phenomenon that has been emulated by many low-salary countries, which is considerably affecting the software industry in developed countries.
We know about several experiences of the sort, and we have undertaken specific action thanks to an opportunity that is actually linked to the solution of this problem in Japan; however, the problem does not only refer to Japan. At the last Hannover Cebit, I had the opportunity to talk to several software and software-related services entrepreneurs mainly from Germany, England and the Netherlands, and they were all sensing the same problem. All of them hire services in India, and yet it is clear for them that they only solve the problem temporarily; all of them clearly see that if everything remains the same, in the mid-term their clients will hire services directly from India.
In other words: the software and software-related services industry in developed, high-salary countries is just not feasible given the current manual development paradigms.
Is this just doomed to be this way?
The know-how syndrome
We live in a culture dominated by the "know-how syndrome." We permanently handle huge amounts of data, little information, and almost zero knowledge. This is the reason why we do not see problems from their real perspective, and therefore fail to solve them.
Reversing the inefficiency: knowledge-based development
How do we revert this? Requirements have to be strictly specified at the "what" level, and for that I need the analyst to understand the "why" and the "what for" -no machine will do this. Then, a person, a business analyst, will describe the "what" and we will figure out how we will go about it: the "how" can always be automated.
If we do it manually, the "what" is not enough; we also have to know the "how", otherwise we will have no idea of how much it is going to cost. However, if we do it with knowledge-based tools, the "what" is enough: what we do is describe instead of program. This means that it is very important for us to turn to a knowledge-based development paradigm, that is, a paradigm where we describe the problem and we do not have to analyze it in its entirety or deduce the complex algorithms to solve it from the problem itself.
Knowledge is permanent, it does not lose its value due to time or technological changes; knowledge is absolutely independent from technology (operating systems, database management systems, language, architectures). What happens to change in knowledge-based development? Someone may say that there is no change; however, that is a lie. Only a dead company is spared from change. There are changes; it is just that they are automatically spread. Knowledge consolidation is automatic; databases are designed and generated automatically; programs are designed and generated automatically; requirements are described at the "what" level.
The importance of knowledge-based development for companies
The influence of a market that is divided into two execution platforms (Java and Microsoft.NET) is very important and has an influence on the rest of the problem. Imagine that I am an end client and there are two platforms. I will have to choose one. Suddenly, three years later I discover that I made a mistake. Fixing the mistake will be very expensive, because as usual, it will mean doing things from scratch for another platform. But if I were a software house, if I were Mariano de Larrobla, for instance, the situation would be quite different. I cannot afford to choose. Choosing means automatically turning my back on one half of the market.
What I am saying is that for a large corporation, knowledge-based development is very important because if its current technological choice does not happen to be the right one, the cost of changing it in the future will be very low. For software houses knowledge-based development is essential.
Technology makes the difference: GeneXus
Now, let us consider the service industry that sells tailor-made services. What do I sell? Do I sell working hours? If this is what I sell, I might as well devote my energy to something different, because I will never be able to have appropriate salaries that will allow me, in Uruguay for instance, to compete with countries where salaries are lower. I have to organize things so that I can sell something else. I can sell work that is measured with some kind of objective measuring unit known by both parties; I can sell work that is measured, for instance, in functional points.
What if, for instance, we make a knowledge-based development in GeneXus? A U.S. company, paying U.S. salaries and working in GeneXus, is in a position to make the same application at a price lower than what the same application would cost in a country with low salaries and low-level programming. Of course, salaries in Uruguay are a bit lower -hopefully they will go up- thus the difference is much greater. Technology makes up for this difference.
What we want are top-notch people, who are efficient working in their countries and receiving good salaries: more than those who receive low salaries but work without technology.
That is the difference; technology makes the difference.
Lecture material: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,938