Brooks was right, or the main difficulty of programming
This article is not about the well-known Brooks Act, which relates the number of people involved in the project and the speed of development, 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 argued (and it’s hard not to agree) that the essence of programming is, first of all, not writing the machine instructions in a specific programming language, but developing a detailed structure of interacting entities representing the essence of the problem area, as well as checking the internal consistency of this structure. Therefore, even if, for example, to invent a computer language operating with concepts at the level of the problem domain, or some other means designed to significantly facilitate software development, programming will still remain a difficult task, since you will have to precisely determine the relationships between objects in the real world, establish exceptions, provide for all possible transitions between states, etc. Consequently, no software development tool can significantly (one or two orders of magnitude) reduce the complexity of development. It is in the description of the structure of interacting entities in the problem area that Brooks sees the main complexity of programming.
When I read a review of this article in S. McConnell's Professional Software Development, I was struck by how far-sighted Brooks turned out in his discourse published more than 20 years ago. An example confirming its correctness nowadays can be visual programming languages ​​(for example, LabVIEW, SFC, LD, etc.) that operate just at the domain level. I immediately found two more examples in my practice.
The office where I work is developing SCADA-systems for energy facilities (state district power station, hydroelectric station, nuclear power plant, thermal power station, 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 workstations for the dispatcher for specific objects. The second department in fact performs the programming at the level of the problem area, using graphic blocks, connecting them with the database and describing additional functionality using a special high-level language. And the complexity and volume of work of this department is no less than that of the programming department.
In parallel with the work, I study in graduate school, develop the environment 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 - a 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 interacting entities of the problem area." Moreover, it seems that this problem cannot be solved by creating a more convenient user interface, as we initially thought. We are working on it now ...
')
What conclusions can be drawn from all this? Well, first of all, we can say that we (programmers) will not stay exactly 50 years without our work in the next few years. Secondly, I would like to caution fellow developers: if you develop a tool environment designed to automate user work, consider whether you don’t stop at the problem described — the need for end-user programming skills (in one form or another).
UPD: moved to the blog "Development"
UPD2: fixed inaccuracies with visual programming languages, thanks to comrade Fortums
Brooks on the complexity of programming
The article was titled “No Silver Bullets - Essence and Accidents of Software Engineering”. It argued (and it’s hard not to agree) that the essence of programming is, first of all, not writing the machine instructions in a specific programming language, but developing a detailed structure of interacting entities representing the essence of the problem area, as well as checking the internal consistency of this structure. Therefore, even if, for example, to invent a computer language operating with concepts at the level of the problem domain, or some other means designed to significantly facilitate software development, programming will still remain a difficult task, since you will have to precisely determine the relationships between objects in the real world, establish exceptions, provide for all possible transitions between states, etc. Consequently, no software development tool can significantly (one or two orders of magnitude) reduce the complexity of development. It is in the description of the structure of interacting entities in the problem area that Brooks sees the main complexity of programming.
Practical confirmation
When I read a review of this article in S. McConnell's Professional Software Development, I was struck by how far-sighted Brooks turned out in his discourse published more than 20 years ago. An example confirming its correctness nowadays can be visual programming languages ​​(for example, LabVIEW, SFC, LD, etc.) that operate just at the domain level. I immediately found two more examples in my practice.
The office where I work is developing SCADA-systems for energy facilities (state district power station, hydroelectric station, nuclear power plant, thermal power station, 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 workstations for the dispatcher for specific objects. The second department in fact performs the programming at the level of the problem area, using graphic blocks, connecting them with the database and describing additional functionality using a special high-level language. And the complexity and volume of work of this department is no less than that of the programming department.
In parallel with the work, I study in graduate school, develop the environment 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 - a 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 interacting entities of the problem area." Moreover, it seems that this problem cannot be solved by creating a more convenient user interface, as we initially thought. We are working on it now ...
')
findings
What conclusions can be drawn from all this? Well, first of all, we can say that we (programmers) will not stay exactly 50 years without our work in the next few years. Secondly, I would like to caution fellow developers: if you develop a tool environment designed to automate user work, consider whether you don’t stop at the problem described — the need for end-user programming skills (in one form or another).
UPD: moved to the blog "Development"
UPD2: fixed inaccuracies with visual programming languages, thanks to comrade Fortums
Source: https://habr.com/ru/post/75036/
All Articles