Bertrand Meyer and Bill Venners discuss the importance of software quality, the market's impact of software quality and the challenge of software complexity.
Bertrand Meyer is a software pioneer that is active in the second border of academic and business. He is currently chairman of the Software Engineering Association of the Swiss Institute of Technology. He has written a quantity of vocabulary papers and books, such as classic "object-oriented software constructs" (Prentice Press, 1994, 2000). In 1985, he founded an interactive software engineering company. The company has renamed Eiffel Software, providing software tools, training and consulting services based on Eiffel language.
On September 28, 2003, Bill Venners made a telephone interview on Bertrand Meyer. In this interview (content will be announced in Artima.com, Meyer has made a lot of software issues, such as software quality, software complexity, contract design, and test drive development. In this first part, Meyer discusses the importance of software quality, market is the challenge of software quality and software complexity.
The importance of software quality
You said in 2001 informit to your interview: "The current situation is very good, so that quality has become a topic of many people in the software world. It will become the most important topic of people." Why is this? " ?
Computer applications have spread all over the social life, so software from quality is not accepted. Software is developing rapidly, and our dependence on software is also increasing. Today, we have to face some problems that have been long- but not valued.
Alan Perlis has a preamble in the preamble of ABELSON and SUSSMAN in a textbook - ABELSON and SUSSMAN - Computer Programming Structure and Analysis. He wrote:
I think computer science is critical to maintain the interestability of "calculation". It is really interesting when it has just happened. Of course, users often pay for it; after a while, we have begun to seriously treat users' complaints. So we believe that he should successfully operate the computer, no mistakes are responsible. I don't look like this. I think we should work hard to extend the function of the computer, so that they have new development directions, let our room full of fun.
A typical attitude is: "You can believe it, we can do anything we want to do. If there is any problem, we will fix it." But this is precisely possible. People's dependence on the software is so large, and they are not likely to accept such attitude. Earlier in the .com era (1996 to 2000), such concepts also barely stood their feet, but it was impossible until 1998. This kind of hitchhiking attitude that can be easily accepted in the past is nowhere.
In May 2003, "Harvard Business Review" published Nicholas Carr's article "IT numbness", the article pointed out: IT did not honor it. This issued an obvious signal: the whole society requires us to have much serious attitude towards yours. Despite the current view, we seem to be able to hitch in (irresponsible), but this era will end quickly. It is increasingly concerned about whether our expenditure is concerned about whether our expenditure can be rewarded. This core is quality.
Market on software quality
Your paper "Trusted Components' Great Challenge" Talks: "The motivation of quality improvements exists, but it is only allowed to reach this level: there is a defect in the market that is not crisisible to product effectiveness. Most managers believe that the quality improvement measures exceeding this range can only produce a sharp drop in investment. "What is the market affecting the quality of the software?
Market forces affect software quality, both positive and negative. This is similar to the River curve theory in the Range Economic Policy. I am not an economist, I also heard that this theory is currently unfundle, so I didn't hit the River curve in the economics. However, the River curve tells us that if you pay taxes at 0%, the country will suffer from disasters because it does not have any income; if it is increased to 100% (can not be high), then people cannot get Any income, so they will refuse to work, so that the country will not have any income. This is a quite simple discussion. Although the River curve has quite obvious rationality at this point, I will undoubtedly determine its correctness and accuracy in economics. However, as a class ratio, it can describe the market forces for software quality. If your software product quality is very bad, you will not get any income, because no one is willing to buy it. Conversely, if you exhaust the time, exhaustion of human, material resources and financial resources to construct absolutely perfect software, then its excessive development cycle and high cost will determine you must exit the market. You don't miss market opportunities, it is eventually exhausted all resources. Therefore, people in the software industry must work hard to find a balanced point: the product is good enough, so it will not be negated immediately in the stage of the assessment; not to pursue the ten beautiful, refined, otherwise it will Can't achieve the goal of time and money.
Complex challenge
Your masterpiece "Object-Oriented Software Construction" said: "Reliability, perhaps with software quality, the only biggest enemy is usually complex." Can you disclose this? "
I think there are some complicated parts that reach the human imagination limit in our software. At some time, these parts allow us to live. The only way to build large, satisfactory systems is not to complicate continuously, and must maintain control of complexity. For example, the Windows XP system contains approximately 4,500 lines of lines, which is completely unique to understand and even imagine. If you want to keep control to them, or if you want to have a little reliability, the only way is to eliminate the parts that are not necessary, and try to keep the complexity control of the rest.
Complexity control is a basic principle in Eiffel language programming. Eiffel is more helpful to people, highly difficult development. Of course, you can build simple, difficult, moderate systems, can even be better than using other tools, but when the problem is complex to more than your will, you can't control its complexity, EIFFEL will True big color. For example, one of its basic principles is to have a corresponding stringent provision for object modularity and hidden information. In many other languages, you can find a simple way to get hidden information, but do not exist in Eiffel. At first, these strict rules may be anger programmers because they can't do what they want, or to write more code to achieve the purpose. But when you need to expand your original design, these rules become a strong guard against a great disaster.
For example, in a much more object-oriented language, despite some restrictions, you can assign a field directly to the field: x.a = 1, where x is an object, A is a field. Anyone with modern methods and object technology is understood why this is wrong. Almost everyone will say: "It is indeed wrong, but in most cases I won't care. I certainly know what I am doing. They are my objects and classes, I should control all of their access interfaces, so you Don't bother me. Don't force me to add some code to pack the modification process of field A. "The surface looks, they are right. There is no problem in the short term, in a small range. Who will I do it? But directly assigning such a typical small problem in you have 10,000, 100,000 or even a million lines of code, there are thousands of classes, many people participate in a project, the project experiences many changes, a lot of modifications, and needs to face different platforms When you bring things to a completely different direction. Direct assignments like object fields will completely disturb the entire architecture. In the end, a small problem will bring a big trouble.
Such a small problem, you can easily fix it in the source code. You only need to prohibit direct access to the object fields like the Eiffel language, and must be done on the encapsulation of the simple process of completing this work - of course, such a process may still need some contracts. This is a problem that is easy to eliminate in the bud phase, but if you don't do this, it will thrive, and finally you will die.
Another example is overload: Different operations are implemented in the same class (method) in the same class. I know that it is controversial for this issue. People have been brainwash, firmly believe that overload is a very good thing, but in essence, it is dangerous, not a good thing. Like the object field directly, the current various languages support overload. In all kinds of libraries prepared, overloading is flooding, using a name (method) to achieve many different operations. On the surface, it has its convenience in the short term, but in the long run, the cost of rising complexity is paid, because you must figure out the exact meaning of each variable in different operations. In fact, the dynamic binding mechanism in the object technology (of course also included EIFFEL can provide people's desired, better flexibility than heavy load.
So, there are many examples to prove that if you are cautious when you program the language design, you can greatly approach the goal of complex control. This may sometimes be why people don't believe in the reasons for our commitment to EIFFEL. The use of Eiffel is very simple; the examples we publish are also very simple, but the reason is not simple in the problem itself, but our solution is simple. Eiffel is actually a stripped person and finding a tool that is often hidden, essentially simplicity. But we now find that people don't believe this, do not believe there is a simple solution. They think that we have hidden some things, this language and these methods do not really solve the practical problems in software development, because they believe that it should be more complex. There is such a vibrant crying: "If it is so good, then it is inevitable." This may be the most stupid saying in history. Many people have this argument, but in front of Eiffel, it is wrong. As long as you use the right tool to solve the problem, you can remove unnecessary complex and find hidden, essentially simple.
Anyone who is building large systems, the central issue of the center of every day is: How to eliminate unnecessary, artificial, self-suite, and control the rest, unacceptable complexity. In this issue, inheritance, contract, generics, and object-oriented development can generally - especially Eiffel - play an important role.
According to my understanding, you should be discussed two things: remove unnecessary complexity and inevitable complexity. I can find some tools such as object-oriented technology and language to help us handle inevitable complexity. But how do tools help us remove the complexity of your find? What does you mean by "Simple to find out the complex back"? Let's see some operating systems now. For example, people violently slammed the complexity of Windows, but I don't think other competitors do better. People did not attack any manufacturers, but it was obvious that some systems did show more confusion. If you re-examine some of the problems mentioned, you can indeed design a better architecture. But from another aspect, the complexity of an operating system cannot be avoided. Windows XP, Redhat Linux and Solaris must handle Unicode, which must provide user interfaces for hundreds of languages. Especially Windows, it must be compatible with a large number of manufacturers who have difficulty counting different devices. This is not the complexity of the kind of self-assessment of the academic criticism. In the real world, we have to face the various requirements of the outside world. Therefore, complexity can be divided into two categories: inevitably complexity, it requires us to deal with it by optimizing organization, analyzing hidden information and modularization, etc.; the other is human complexity, we should simplify Solve the problem to eliminate it.
