Tom DeMarco: software engineering - an idea whose time has passed?
I often communicate with people on flexible software development methods, sometimes I write articles about it (for example, a recent article on Habré about Kanban in IT ).
And I can say that the main argument that people bring against these methods, which stops many even from thinking about Kanban, Scrum or XP, is the supposedly low level of control over the development of these methodologies.
At the same time, some perceive, as unprofessionalism, the arguments that the level of control does not greatly depend on the methodology, and indeed, control in the field of software development is generally a fiction.
For these people, I translated a new article by Tom DeMarco, one of the founders of software engineering, a developer of software metrics, and a co-author of the famous book Human Factor: Successful Projects and Teams.
This article is highly provocative and is now widely discussed in English-language blogs and it is strange that I have not yet met her translations into Russian. But, despite the provocation, there are some very correct ideas in it that can change someone’s perception of the importance and ability to control the development.
In general, read the translation of the article under the cut.
Tom DeMarco: Software Engineering - an idea whose time has passed?
')
Most recently, the 40th anniversary of the NATO Conference on Software Engineering (Software Engineering), which was held in Garmisch, Germany. It was there that the engineering discipline for software was first proposed.
Since my early books have become part of this new discipline, now it seems like a great time to revise, revise positions. My early book on metrics, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall / Yourdon Press, 1982) , played a large role in how many outstanding developers shared their work and planned their projects.
And now I’m wondering if these tips were right in the past, are they still valid, and do I still believe that metrics are necessary for any successful development project?
My answers are NO, NO and NO.
A book for me is a curious combination of generally true things written on every page, but all together they create a common message that is wrong.
As if the young author of the book never met metrics that he would not like. The deep meaning of the book is that metrics are good and the more metrics the better.
Now we all understand that metrics cost money and time and must be used with cautious moderation.
In addition, software development is essentially different from natural science, such as physics, and the metrics because of this are much less accurate. And they should be considered very skeptical, not unconditionally.
Subordinate to control
The most quoted line of my book is the very first sentence:
"You can not control what you can not measure"
This sentence is true, but I find more and more that my use of this sentence is incorrect. The proposal implies that control is an important aspect, perhaps the most important for any software development project.
But it is not so!
Many projects developed without any control, but still the result was excellent products such as GoogleEarth or Wikipedia.
To understand the real role of control, you need to understand the difference between two completely different types of projects :
“Project A” will ultimately cost $ 1 million and will bring a profit (value) of approximately $ 1.1 million.
“Project B” will ultimately cost about a million dollars and will bring a profit (value) of more than 50 million.
It immediately becomes clear that control is really very important for project A, but absolutely not important for project B. This leads us to a completely strange conclusion that tight control is something that is very important for relatively useless projects and much less important for useful projects.
This suggests that the more you focus on control, the more likely it is that you are working on a project that will ultimately bring very little profit.
I think the much more important question is “For what the devil are we doing so many projects that bring so little profit?”
Can I really say that it’s normal to run projects without control or with relatively little control? Practically!
I assume that first we need to choose projects where precise control will not be needed so much. Next we need to reduce our expectations of how much we will control it, no matter how hard we try to do it.
Disturbing analogy
Imagine that you are trying to control the upbringing of a teenager. The very idea of controlling your child may seem a little exciting, unpleasant. In addition, the rate that you succeed, can not be high.
If you fail this task, fail completely, then it can destroy someone's life. So it is obvious that you will not loosen your grip completely and do not release the teenager in the free swimming.
So you, as a swordsman, learning to hold your sword, as if it were a bird: too much and the bird would be damaged; too weak and she will fly away ...
Now apply the rule “You cannot control what you cannot measure” to the teenager. Most of the things that are really important - honor, dignity, discipline, personality, politeness under pressure, values, ethics, ingenuity, loyalty, humor, goodwill - they are not measurable.
You should just guide your child as well as you can without any help from any kind of metrics. And this is difficult, but raising children is difficult.
You will have some “measures” in the form of school grades, and you are grateful for that. But you also know that a math grade for your child is a better indicator of achievement than a grade for Spanish, since understanding mathematics is easier to measure.
And his assessment of the behavior is likely to tell you a lot more about the teacher than about the child.
So how do you manage a project without control?
Well, you control people and control time and money. You tell the team leader, for example:
“I know the final date, and I'm not even going to tell you about it. One day I will come to you and say that the project will end in a week - you must be ready to finish all the work and do what you have with the finished product. Your task is to work incrementally, adding pieces to the project in order of importance, and doing the integration, documentation and testing incrementally and constantly. ”
This may sound like a recommendation of flexible methods, but I’m too far from creating software to recommend at the level of methods. Rather, I recommend a managerial approach — one that can lead the team towards flexible methods, at least towards incremental ideas from the school of agile development.
So far, I have mainly discussed the metrics from software engineering (Software Engineering). What about the rest?
Little by little I come to the conclusion that Software Engineering is an idea whose time has come and gone!
I still believe that there is a huge sense in software engineering. But this is not exactly what software engineering has come to mean. This term surrounds a specific set of disciplines, including a specific process, expertise and research, requirements development, metrics, engineering, quality control, rigorous planning and tracking, coding standards and documentation.
All this is necessary for the logic of the practice and for predictability. Logicality and predictability are still desirable, but they were never the most important things.
For the past 40 years, for example, we have been torturing ourselves for not being able to complete projects on time and without exceeding the budget. But, as I noted earlier, a much more important goal is to create software that changes the world, or that transforms a company or how it conducts its business. We were rather much successful in changes that often occur out of control.
Software development is and always will be something experimental. Yes, the creation of the program itself is not necessarily experimentally, but the concept of the program is always.
And this is exactly the place where we need to focus. And this is the place where we always had to focus before.
And I can say that the main argument that people bring against these methods, which stops many even from thinking about Kanban, Scrum or XP, is the supposedly low level of control over the development of these methodologies.
At the same time, some perceive, as unprofessionalism, the arguments that the level of control does not greatly depend on the methodology, and indeed, control in the field of software development is generally a fiction.
For these people, I translated a new article by Tom DeMarco, one of the founders of software engineering, a developer of software metrics, and a co-author of the famous book Human Factor: Successful Projects and Teams.
This article is highly provocative and is now widely discussed in English-language blogs and it is strange that I have not yet met her translations into Russian. But, despite the provocation, there are some very correct ideas in it that can change someone’s perception of the importance and ability to control the development.
In general, read the translation of the article under the cut.
Tom DeMarco: Software Engineering - an idea whose time has passed?
')
Most recently, the 40th anniversary of the NATO Conference on Software Engineering (Software Engineering), which was held in Garmisch, Germany. It was there that the engineering discipline for software was first proposed.
Since my early books have become part of this new discipline, now it seems like a great time to revise, revise positions. My early book on metrics, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall / Yourdon Press, 1982) , played a large role in how many outstanding developers shared their work and planned their projects.
And now I’m wondering if these tips were right in the past, are they still valid, and do I still believe that metrics are necessary for any successful development project?
My answers are NO, NO and NO.
A book for me is a curious combination of generally true things written on every page, but all together they create a common message that is wrong.
As if the young author of the book never met metrics that he would not like. The deep meaning of the book is that metrics are good and the more metrics the better.
Now we all understand that metrics cost money and time and must be used with cautious moderation.
In addition, software development is essentially different from natural science, such as physics, and the metrics because of this are much less accurate. And they should be considered very skeptical, not unconditionally.
Subordinate to control
The most quoted line of my book is the very first sentence:
"You can not control what you can not measure"
This sentence is true, but I find more and more that my use of this sentence is incorrect. The proposal implies that control is an important aspect, perhaps the most important for any software development project.
But it is not so!
Many projects developed without any control, but still the result was excellent products such as GoogleEarth or Wikipedia.
To understand the real role of control, you need to understand the difference between two completely different types of projects :
“Project A” will ultimately cost $ 1 million and will bring a profit (value) of approximately $ 1.1 million.
“Project B” will ultimately cost about a million dollars and will bring a profit (value) of more than 50 million.
It immediately becomes clear that control is really very important for project A, but absolutely not important for project B. This leads us to a completely strange conclusion that tight control is something that is very important for relatively useless projects and much less important for useful projects.
This suggests that the more you focus on control, the more likely it is that you are working on a project that will ultimately bring very little profit.
I think the much more important question is “For what the devil are we doing so many projects that bring so little profit?”
Can I really say that it’s normal to run projects without control or with relatively little control? Practically!
I assume that first we need to choose projects where precise control will not be needed so much. Next we need to reduce our expectations of how much we will control it, no matter how hard we try to do it.
Disturbing analogy
Imagine that you are trying to control the upbringing of a teenager. The very idea of controlling your child may seem a little exciting, unpleasant. In addition, the rate that you succeed, can not be high.
If you fail this task, fail completely, then it can destroy someone's life. So it is obvious that you will not loosen your grip completely and do not release the teenager in the free swimming.
So you, as a swordsman, learning to hold your sword, as if it were a bird: too much and the bird would be damaged; too weak and she will fly away ...
Now apply the rule “You cannot control what you cannot measure” to the teenager. Most of the things that are really important - honor, dignity, discipline, personality, politeness under pressure, values, ethics, ingenuity, loyalty, humor, goodwill - they are not measurable.
You should just guide your child as well as you can without any help from any kind of metrics. And this is difficult, but raising children is difficult.
You will have some “measures” in the form of school grades, and you are grateful for that. But you also know that a math grade for your child is a better indicator of achievement than a grade for Spanish, since understanding mathematics is easier to measure.
And his assessment of the behavior is likely to tell you a lot more about the teacher than about the child.
So how do you manage a project without control?
Well, you control people and control time and money. You tell the team leader, for example:
“I know the final date, and I'm not even going to tell you about it. One day I will come to you and say that the project will end in a week - you must be ready to finish all the work and do what you have with the finished product. Your task is to work incrementally, adding pieces to the project in order of importance, and doing the integration, documentation and testing incrementally and constantly. ”
This may sound like a recommendation of flexible methods, but I’m too far from creating software to recommend at the level of methods. Rather, I recommend a managerial approach — one that can lead the team towards flexible methods, at least towards incremental ideas from the school of agile development.
So far, I have mainly discussed the metrics from software engineering (Software Engineering). What about the rest?
Little by little I come to the conclusion that Software Engineering is an idea whose time has come and gone!
I still believe that there is a huge sense in software engineering. But this is not exactly what software engineering has come to mean. This term surrounds a specific set of disciplines, including a specific process, expertise and research, requirements development, metrics, engineering, quality control, rigorous planning and tracking, coding standards and documentation.
All this is necessary for the logic of the practice and for predictability. Logicality and predictability are still desirable, but they were never the most important things.
For the past 40 years, for example, we have been torturing ourselves for not being able to complete projects on time and without exceeding the budget. But, as I noted earlier, a much more important goal is to create software that changes the world, or that transforms a company or how it conducts its business. We were rather much successful in changes that often occur out of control.
Software development is and always will be something experimental. Yes, the creation of the program itself is not necessarily experimentally, but the concept of the program is always.
And this is exactly the place where we need to focus. And this is the place where we always had to focus before.
Source: https://habr.com/ru/post/65343/
All Articles