Brooks was right, or the main difficulty of programming
This article is not about Brooks’s famous law relating the number of people involved in a project and development speed, but about a less well-known article written by him back in 1987.
The article was titled No Silver Bullets - Essence and Accidents of Software Engineering. It stated (and it is difficult to disagree with it) that the essence of programming is, first of all, not writing instructions to the machine in a specific programming language, but developing a detailed structure of interacting entities representing the entities of the problem area, as well as checking the internal consistency of this structure. Therefore, even if, for example, inventing a computer language that operates with concepts at the level of a problem area, or some other tool designed to significantly facilitate software development, programming will still remain a difficult task, since it will be necessary to accurately determine the relationships between real-world objects, to establish exceptions, provide for all possible transitions between states, etc. Therefore, no software development tool can significantly (by one or two orders of magnitude) reduce the complexity of development. It is in the description of the structure of interacting entities of the problem domain that Brooks sees the main complexity of programming.
When I read a review of this article in S. McConnell's book, Professional Software Development, I was amazed at how far-sighted Brooks was in his discourse published more than 20 years ago. An example confirming its correctness in our time can be visual programming languages (for example, LabVIEW, SFC, LD, etc.), operating just at the level of the subject area. I immediately found two more examples in my practice.
The office in which I work is engaged in the development of SCADA systems for energy facilities (state district power plants, hydroelectric power stations, nuclear power plants, thermal power plants, etc.). It is divided into 2 departments: the programming department, which develops the system as a whole, and the design department, which is engaged in the development of graphic dispatcher workstations for specific objects. The second department essentially performs programming at the level of the problem area, using graphic blocks, linking them to the database and describing additional functionality using a special high-level language. And the complexity and amount of work of this department is no less than that of the programming department.
In parallel with work, I am studying in graduate school, developing a medium for modeling the genetic development of organisms. Now we have developed a fairly universal modeling system that allows the researcher to describe the vital processes of organisms using a set of fairly simple mathematical rules. And here we are faced with the fact that for the end user - the biologist - the creation of this description, based on experimental data, is the main problem. This is due precisely to the need to "develop a detailed structure of the interacting entities of the problem area." Moreover, it seems that this problem cannot be solved by creating a more convenient user interface, as it seemed to us at first. Now we are working on it ...
What conclusions can be drawn from all this? Well, firstly, we can say that we (programmers) without our work in the next 50 years will definitely not remain so. Secondly, I would like to caution fellow developers: if you are developing a tool environment designed to automate the work of users, think about whether you run into the problem described above - the end user needs programming skills (in one form or another).
UPD: moved to the "Development"
blog UPD2: fixed inaccuracies with visual programming languages, thanks to Comrade Fortums
Brooks on the difficulty of programming
The article was titled No Silver Bullets - Essence and Accidents of Software Engineering. It stated (and it is difficult to disagree with it) that the essence of programming is, first of all, not writing instructions to the machine in a specific programming language, but developing a detailed structure of interacting entities representing the entities of the problem area, as well as checking the internal consistency of this structure. Therefore, even if, for example, inventing a computer language that operates with concepts at the level of a problem area, or some other tool designed to significantly facilitate software development, programming will still remain a difficult task, since it will be necessary to accurately determine the relationships between real-world objects, to establish exceptions, provide for all possible transitions between states, etc. Therefore, no software development tool can significantly (by one or two orders of magnitude) reduce the complexity of development. It is in the description of the structure of interacting entities of the problem domain that Brooks sees the main complexity of programming.
Practical confirmation
When I read a review of this article in S. McConnell's book, Professional Software Development, I was amazed at how far-sighted Brooks was in his discourse published more than 20 years ago. An example confirming its correctness in our time can be visual programming languages (for example, LabVIEW, SFC, LD, etc.), operating just at the level of the subject area. I immediately found two more examples in my practice.
The office in which I work is engaged in the development of SCADA systems for energy facilities (state district power plants, hydroelectric power stations, nuclear power plants, thermal power plants, etc.). It is divided into 2 departments: the programming department, which develops the system as a whole, and the design department, which is engaged in the development of graphic dispatcher workstations for specific objects. The second department essentially performs programming at the level of the problem area, using graphic blocks, linking them to the database and describing additional functionality using a special high-level language. And the complexity and amount of work of this department is no less than that of the programming department.
In parallel with work, I am studying in graduate school, developing a medium for modeling the genetic development of organisms. Now we have developed a fairly universal modeling system that allows the researcher to describe the vital processes of organisms using a set of fairly simple mathematical rules. And here we are faced with the fact that for the end user - the biologist - the creation of this description, based on experimental data, is the main problem. This is due precisely to the need to "develop a detailed structure of the interacting entities of the problem area." Moreover, it seems that this problem cannot be solved by creating a more convenient user interface, as it seemed to us at first. Now we are working on it ...
conclusions
What conclusions can be drawn from all this? Well, firstly, we can say that we (programmers) without our work in the next 50 years will definitely not remain so. Secondly, I would like to caution fellow developers: if you are developing a tool environment designed to automate the work of users, think about whether you run into the problem described above - the end user needs programming skills (in one form or another).
UPD: moved to the "Development"
blog UPD2: fixed inaccuracies with visual programming languages, thanks to Comrade Fortums