Programming ≠ computer science
Software development seems to be for the worse different from other disciplines of computer science.
A few years ago I studied algorithms and complexity. A delightfully clean area, where each concept is clearly defined, each result is based on previous evidence. When you learn a fact in this area, you can rely on it, since the mathematics itself led it out. Even imperfect results, like approximation and probabilistic algorithms, have a rigorous analysis of their imperfections. Other computer science disciplines, such as network topology and cryptography, have the same satisfactory status.
And now I'm working with software development, and this is an unbearably slippery topic. No concept is precisely defined. Results are rated with “generally” or “overall.” Today’s research may or may not help tomorrow’s work. New approaches often refute previous methods, while they themselves burn brightly for a short time, and then go out of fashion when their limitations emerge. We believed in structured programming. Then they began to believe in fourth-generation languages, then in object-oriented methods, then in extreme programming, and now, maybe, in open source.
But programming is exactly the place where the tire comes in contact with asphalt. Few people care if equals , purely for the beauty of the issue. The computer area deals with computers. This writing programs to solve real human problems and the work of these programs on real machines. According to the Church-Turing thesis , all computer equipment is essentially equivalent. So while the computer architecture is awesome, the problem of creating software remains the real limitation in computer science. We need programs that can be assembled in a reasonable time and at a reasonable cost, which work approximately as planned by the designers, and work without errors.
')
Having such a goal, I was always concerned with one question (like many other researchers): why can't programmers get more rigorous results, as in other areas of computer science? If you ask otherwise, “What part of the architecture and design of the programs can be made formal and proof?” The answer to this question is in Figure 1.
Figure 1: Bright line in computer science
Topics above this line belong to software development. The areas of study below this line are the main informatics subjects. The latter have clear, formal results. For open problems in this area, we expect new results to be formally formulated. These themes are based on each other: cryptography on complexity, and compilers on algorithms, for example. Moreover, we believe that the proven results in these areas will remain so in 100 years.
So what is this bright line, and why is there not one of the programming themes below it? A line is a quality called "direct human participation." Software development has this quality, but traditional computer science does not have it. The results from the disciplines below the line can be used by people, but these results are not directly influenced by people.
Software development has an inherent human component. For example, the operational reliability of software is the ability to understand, locate, and correct a person's defects in a software system. Some formal computer science concepts can affect operational reliability — perhaps the cyclomatic complexity of a software control graph. But operational reliability is critically dependent on people and their ability to comprehend the meaning and design of the source code. It is impossible to answer the question whether a particular software system has high operational reliability simply by mechanically studying the software.
Same with security. Researchers used some formal methods to find out the effect of a software system on people's health and property. But no discussion about program security can be considered complete without referring to the human component of the system under study. Similarly, for the development of requirements. We can develop any survey technique to ensure that we have exact requirements from our stakeholders, and we can create different systems to record them. But no amount of research in this area will change the fact that gathering demands often involves talking or observing people. Sometimes these people give us the right information, and sometimes they don’t. Sometimes people lie, perhaps for valid reasons. Sometimes people honestly try to convey the right information, but they can't do it.
This observation leads to the Thesis of Connell:
This is an extra-mathematical statement about the boundaries of formal systems. I have no evidence for or against. But the fact is that human problems remain central to software development:
All these problems revolve around people.
My thesis explains why software development is so difficult and so slippery. Proven methods of one team of programmers do not work for other teams. A comprehensive analysis of past projects may be useless for a good evaluation of the following. Each of the revolutionary development tools helps a little bit, and then does not meet its great promises. The reason is that people are too soft, frustrating and unpredictable.
Before turning to the implications of my statement, consider three possible objections:
In some ways, this objection is true, but not in everything. I argue that a set of disciplines, commonly called software engineering, will continue to essentially defy a rigorous solution. Narrow aspects of some problems may be amenable to the formal approach, but their success will be only on the periphery of key development problems.
These methods generally solve the evaluation problem and include Function Point Counting, COCOMO II , PROBE, and others. Despite their mathematical form, these methods are not evidence or formal results. Such statistics is simply an attempt to quantify the subjective human experience on past software projects and to extrapolate it to future projects. Sometimes it works. But outwardly strict formulas in these schemes are a pig with lipstick, if we use the modern expression. For example, one of the formulas in COCOMO II looks like this: where , but - This is a set of five scaling factors , such as "development flexibility" and "team cohesion." The formula itself looks strictly, but it is dominated by an indicator composed of human factors.
Indeed, researchers of formal processes demonstrate progress in solving various problems. But they can be convicted of violating the very first objection in this list: they define the software development too narrowly for it to be rigorously resolved. Formal methods simply conveniently interpret for themselves any problem that is based on human participation and interpretation. For example, a key element of formal development methods is the creation of rigorous, unambiguous specifications. These specifications are then used to conduct (and prove) the next stages of development. Of course, the formal method may contain an unambiguous semantic notation scheme. But no formal method contains an exact recipe for how to translate into an unambiguous state the vague thoughts of people about what the program should do.
Contrary to these objections, I declare that software development is essentially different from traditional, formal informatics. The first depends on the people, and the second - not. This leads us to the Concnell Conclusion:
For example, David Parnas in 1972 wrote a remarkable scientific article " On the criteria for the expansion of the system into modules ." She describes a simple experiment that Parnassus conducted with alternative software design strategies, one with information hiding, and the other with global data visibility. Then, on the basis of this small experiment, he drew several conclusions and made recommendations. Nothing in the article is not proven, and Parnas does not guarantee that, following the recommendations, everyone will receive a similar result. But the article contains wise advice and greatly influenced the popularity of object-oriented programming languages.
Another example is the great work of the Institute for Software Engineering at Carnegie Mellon University, known as CMMI . CMMI started out as a software development process model, and now it has grown to include other types of projects. The CMMI is about 1,000 pages — not counting examples, interpretations, and teaching materials — and it represents more than 1,000 person-years of work. Many large organizations have used it and have made significant progress in their software development processes and products. But in CMMI there is not a single firmly proven result. This is just a set of (well-developed) proposals on how to organize a software project based on methods that have been effective for other organizations in the past. In fact, the Institute for Software Engineering states that CMMI is not even a process, but rather a meta-process, the details of which are filled in by each organization.
Other areas of research in the same vein are design patterns, architecture styles, refactoring based on dubious methods, flexible development methodology, and data visualization. These disciplines may partially contain proven results, but generally focus on systems that initially contain human participation. To clarify: key informatics topics (below the bright line) are vital tools for any developer. Knowledge of algorithms is important when designing high-performance applications. Queuing theory helps to design the core of the operating system. The clean room methodology is also useful in some situations. Analyzing statistics can be useful when planning similar projects with a similar group of participants. But formalism is just a necessary, not a sufficient condition for a good design. Let's take the example of construction and architecture (that is, houses and buildings).
Imagine a brilliant construction engineer, the world's best expert in building materials, stress dependence on stress, load distribution, wind shear and tremors, etc. This guy is listed in the notebooks of architects in all countries to call him consultations on each construction project. Will this mythical civil engineer be as good at designing buildings that he analyzes? Not at all. He may be lost in conversations with customers, unable to design places that are pleasant to live in, his imagination is not enough to come up with solutions for new problems, and he is bored. The construction technique is useful for real architects, but not enough for a good project. Successful architecture requires creativity, concept, interdisciplinary thinking and humanism.
In the same way, classical computer science is useful in software development, but it will never be enough. Designing good software also requires creativity, concept, interdisciplinary thinking and humanism. This observation frees software development researchers. They can spend time exploring successful methods - accumulating a body of collective knowledge for future practitioners. We do not have to squeeze software development into a computer science expansion framework on a mathematical basis. It does not work and can distract us from useful discoveries that are still waiting for their time.
Acknowledgments
Thanks to Steve Homer for the discussion that sparked my interest in this issue.
A few years ago I studied algorithms and complexity. A delightfully clean area, where each concept is clearly defined, each result is based on previous evidence. When you learn a fact in this area, you can rely on it, since the mathematics itself led it out. Even imperfect results, like approximation and probabilistic algorithms, have a rigorous analysis of their imperfections. Other computer science disciplines, such as network topology and cryptography, have the same satisfactory status.
And now I'm working with software development, and this is an unbearably slippery topic. No concept is precisely defined. Results are rated with “generally” or “overall.” Today’s research may or may not help tomorrow’s work. New approaches often refute previous methods, while they themselves burn brightly for a short time, and then go out of fashion when their limitations emerge. We believed in structured programming. Then they began to believe in fourth-generation languages, then in object-oriented methods, then in extreme programming, and now, maybe, in open source.
But programming is exactly the place where the tire comes in contact with asphalt. Few people care if equals , purely for the beauty of the issue. The computer area deals with computers. This writing programs to solve real human problems and the work of these programs on real machines. According to the Church-Turing thesis , all computer equipment is essentially equivalent. So while the computer architecture is awesome, the problem of creating software remains the real limitation in computer science. We need programs that can be assembled in a reasonable time and at a reasonable cost, which work approximately as planned by the designers, and work without errors.
')
Having such a goal, I was always concerned with one question (like many other researchers): why can't programmers get more rigorous results, as in other areas of computer science? If you ask otherwise, “What part of the architecture and design of the programs can be made formal and proof?” The answer to this question is in Figure 1.
Figure 1: Bright line in computer science
Topics above this line belong to software development. The areas of study below this line are the main informatics subjects. The latter have clear, formal results. For open problems in this area, we expect new results to be formally formulated. These themes are based on each other: cryptography on complexity, and compilers on algorithms, for example. Moreover, we believe that the proven results in these areas will remain so in 100 years.
So what is this bright line, and why is there not one of the programming themes below it? A line is a quality called "direct human participation." Software development has this quality, but traditional computer science does not have it. The results from the disciplines below the line can be used by people, but these results are not directly influenced by people.
Software development has an inherent human component. For example, the operational reliability of software is the ability to understand, locate, and correct a person's defects in a software system. Some formal computer science concepts can affect operational reliability — perhaps the cyclomatic complexity of a software control graph. But operational reliability is critically dependent on people and their ability to comprehend the meaning and design of the source code. It is impossible to answer the question whether a particular software system has high operational reliability simply by mechanically studying the software.
Same with security. Researchers used some formal methods to find out the effect of a software system on people's health and property. But no discussion about program security can be considered complete without referring to the human component of the system under study. Similarly, for the development of requirements. We can develop any survey technique to ensure that we have exact requirements from our stakeholders, and we can create different systems to record them. But no amount of research in this area will change the fact that gathering demands often involves talking or observing people. Sometimes these people give us the right information, and sometimes they don’t. Sometimes people lie, perhaps for valid reasons. Sometimes people honestly try to convey the right information, but they can't do it.
This observation leads to the Thesis of Connell:
Software development will never be a strict discipline with proven results, because it involves human activity.
This is an extra-mathematical statement about the boundaries of formal systems. I have no evidence for or against. But the fact is that human problems remain central to software development:
- What should this program do? (requirements, usability, safety)
- What should the program look like inside so that it can be easily repaired and modified? (architecture, design, scalability, portability, extensibility)
- How long will it take to write? (assessment)
- How should we develop it? (coding, testing, measuring, configuration)
- How should the team work effectively? (management, process, documentation)
All these problems revolve around people.
My thesis explains why software development is so difficult and so slippery. Proven methods of one team of programmers do not work for other teams. A comprehensive analysis of past projects may be useless for a good evaluation of the following. Each of the revolutionary development tools helps a little bit, and then does not meet its great promises. The reason is that people are too soft, frustrating and unpredictable.
Before turning to the implications of my statement, consider three possible objections:
Thesis realizes itself. If any area of software development is suddenly solved strictly, then you can simply change the definition of software development to eliminate this problem from it.
In some ways, this objection is true, but not in everything. I argue that a set of disciplines, commonly called software engineering, will continue to essentially defy a rigorous solution. Narrow aspects of some problems may be amenable to the formal approach, but their success will be only on the periphery of key development problems.
Statistical results in programming already refute this thesis.
These methods generally solve the evaluation problem and include Function Point Counting, COCOMO II , PROBE, and others. Despite their mathematical form, these methods are not evidence or formal results. Such statistics is simply an attempt to quantify the subjective human experience on past software projects and to extrapolate it to future projects. Sometimes it works. But outwardly strict formulas in these schemes are a pig with lipstick, if we use the modern expression. For example, one of the formulas in COCOMO II looks like this: where , but - This is a set of five scaling factors , such as "development flexibility" and "team cohesion." The formula itself looks strictly, but it is dominated by an indicator composed of human factors.
Formal development processes, such as the “clean room” method, gradually find rigorous, demonstrable methods. They raise a bright line to bring under it previously blurred threads.
Indeed, researchers of formal processes demonstrate progress in solving various problems. But they can be convicted of violating the very first objection in this list: they define the software development too narrowly for it to be rigorously resolved. Formal methods simply conveniently interpret for themselves any problem that is based on human participation and interpretation. For example, a key element of formal development methods is the creation of rigorous, unambiguous specifications. These specifications are then used to conduct (and prove) the next stages of development. Of course, the formal method may contain an unambiguous semantic notation scheme. But no formal method contains an exact recipe for how to translate into an unambiguous state the vague thoughts of people about what the program should do.
Contrary to these objections, I declare that software development is essentially different from traditional, formal informatics. The first depends on the people, and the second - not. This leads us to the Concnell Conclusion:
Attempts should be made to prove fundamental software development results and recognize that significant advances in this area will be only general recommendations.
For example, David Parnas in 1972 wrote a remarkable scientific article " On the criteria for the expansion of the system into modules ." She describes a simple experiment that Parnassus conducted with alternative software design strategies, one with information hiding, and the other with global data visibility. Then, on the basis of this small experiment, he drew several conclusions and made recommendations. Nothing in the article is not proven, and Parnas does not guarantee that, following the recommendations, everyone will receive a similar result. But the article contains wise advice and greatly influenced the popularity of object-oriented programming languages.
Another example is the great work of the Institute for Software Engineering at Carnegie Mellon University, known as CMMI . CMMI started out as a software development process model, and now it has grown to include other types of projects. The CMMI is about 1,000 pages — not counting examples, interpretations, and teaching materials — and it represents more than 1,000 person-years of work. Many large organizations have used it and have made significant progress in their software development processes and products. But in CMMI there is not a single firmly proven result. This is just a set of (well-developed) proposals on how to organize a software project based on methods that have been effective for other organizations in the past. In fact, the Institute for Software Engineering states that CMMI is not even a process, but rather a meta-process, the details of which are filled in by each organization.
Other areas of research in the same vein are design patterns, architecture styles, refactoring based on dubious methods, flexible development methodology, and data visualization. These disciplines may partially contain proven results, but generally focus on systems that initially contain human participation. To clarify: key informatics topics (below the bright line) are vital tools for any developer. Knowledge of algorithms is important when designing high-performance applications. Queuing theory helps to design the core of the operating system. The clean room methodology is also useful in some situations. Analyzing statistics can be useful when planning similar projects with a similar group of participants. But formalism is just a necessary, not a sufficient condition for a good design. Let's take the example of construction and architecture (that is, houses and buildings).
Imagine a brilliant construction engineer, the world's best expert in building materials, stress dependence on stress, load distribution, wind shear and tremors, etc. This guy is listed in the notebooks of architects in all countries to call him consultations on each construction project. Will this mythical civil engineer be as good at designing buildings that he analyzes? Not at all. He may be lost in conversations with customers, unable to design places that are pleasant to live in, his imagination is not enough to come up with solutions for new problems, and he is bored. The construction technique is useful for real architects, but not enough for a good project. Successful architecture requires creativity, concept, interdisciplinary thinking and humanism.
In the same way, classical computer science is useful in software development, but it will never be enough. Designing good software also requires creativity, concept, interdisciplinary thinking and humanism. This observation frees software development researchers. They can spend time exploring successful methods - accumulating a body of collective knowledge for future practitioners. We do not have to squeeze software development into a computer science expansion framework on a mathematical basis. It does not work and can distract us from useful discoveries that are still waiting for their time.
Acknowledgments
Thanks to Steve Homer for the discussion that sparked my interest in this issue.
Source: https://habr.com/ru/post/335160/
All Articles