До сего момента мы рассматривали управление Существенной Сложностью (Essential Complexity). Это наиболее существенное, хотя и не исчерпывающее, условие успешности разработки, потому что "Серебрянной пули нет".

Существенная Сложность (Essential Complexity) - сложность того, что делает система, сложность реализованных ею моделей, отражающих сложность реального мира, не зависящая от способа и деталей реализации. Сложность, порожденная решаемой проблемой, и ничто не может устранить или уменьшить её. Мы можем только управлять ею таким образом, чтобы минимизировать объем существенной сложности, рассматриваемой одновременно, до уровня, не превосходящего ограничения краткосрочной памяти человека.

Как утверждает Steve McConnell:

💬 "В философии существенными называют свойства, которыми объект должен обладать, чтобы быть именно этим объектом. Автомобиль должен иметь двигатель, колеса и двери — если объект не обладает каким-нибудь из этих существенных свойств, это не автомобиль."
-- "Code Complete" by Steve McConnell

Побочная Сложность (Accidental Complexity) - сложность, возникающая в процессе реализации, например, количество классов в программе образуют побочную сложность. Выделение уровня абстракции введением еще одного класса повышает уровень косвенности в программе, т.е. программа увеличивает свою сложность, но при этом повышается способность управлять существенной сложностью, т.к. возникает возможность абстрагироваться от нерелевантных деталей, а значит, уменьшить количество единиц сложности, рассматриваемых одновременно.

Как утверждает Steve McConnell:

💬 "Несущественными (акцидентными, побочными) свойствами называют свойства, которыми объект обладает в силу случайности, — свойства, не влияющие на его суть. Так, автомобиль может иметь четырехцилиндровый двигатель с турбонаддувом, восьмицилиндровый или любой другой и все же являться автомобилем. Тип двигателя и колес, число дверей — все это несущественные свойства. Можете также думать о них как о второстепенных, произвольных, необязательных и случайных."
-- "Code Complete" by Steve McConnell

Ввел эти термины в оборот Frederick P. Brooks в своей монументальной статье "No Silver Bullets: Essence and Accidents of Software Engineering", позаимствовав идею у Аристотеля.

💬 "Following Aristotle, I divide them [difficulties] into essence - the difficulties inherent in the nature of the software - and accidents - those difficulties that today attend its production but that are not inherent.
<...>
The complexity of software is in essential property, not an accidental one. Hence denoscriptions of a software entity that abstract away its complexity often abstract away its essence. Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties experimentally. This worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.”
—“No Silver Bullet - Essence and Accident in Software Engineering” by Frederick P. Brooks, Jr.

Теперь мы подошли к вопросу о том, каким образом можно защитить управление существенной сложностью от несущественной сложности.

Если есть изменяемое состояние, значит, систему можно привести в логически бессмысленное состояние. Чтобы этого избежать и сохранить систему в логически согласованном состоянии, эти изменения должны соответствовать инвариантам (бизнес-правилам).

А если в коде уже реализованы существующие инварианты, значит, их можно нарушить или вступить с ними в противоречие, когда мы изменяем код.

А чтобы не вступить в противоречие с ними, мы должны осмыслить уже реализованные инварианты и удостовериться в том, что, добавляя новые инварианты, мы не нарушаем существующих.

А поскольку инварианты выражены методами, то чем меньше дистанция между изменяемым состоянием и этими методами, тем быстрее и легче можно их осмыслить. Это способ обойти ограничение краткосрочной памяти человека (Закон Миллера).

Инкапсуляция дает нам гарантию того, что ничто, кроме осмысленных нами методов, не изменяет это состояние в обход инвариантов, а значит, поиск и осмысление инвариантов можно ограничить этими методами.

💬 encapsulation, the fact that one cannot see, much less design, the inner structure of the pieces.
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

Брешь в инкапсуляции означает то, что поиск инвариантов безграничен в пределах всего объема кода (именно по этой причине стоит избегать глобальных переменных).

В Функциональной Парадигме нет изменяемого состояния, поэтому, нет необходимости в инкапсуляции.

Существует два способа управления сложностью:
1. Сократить дистанцию между изменяемым состоянием и его инвариантами (OOP).
2. Сократить саму изменяемость (FP).

💬 "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts."
– Michael Feathers

Под "moving parts" подразумевается изменяемое состояние, т.е. речь идет о конкретном виде инкапсуляции - сокрытии состяния и экспонировании поведения.

Как вы поняли, этот пост о про Anemic Domain Models, которые не используют ни функционального, ни объектно-ориентированного способа управления сложностью.

David Parnas в своем письме к Frederick P. Brooks писал:

💬 "Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срeдствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.

The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad de-signs with these languages and get very little value from them. If the value is small, it won't catch on."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

Из этого письма следует, что ООП не приживается именно там, где не умеют проектировать, а значит, не умеют извлекать выгоду из проектирования.

Разумеется, дело не в самом ООП, как в инструменте, а в его способности поддерживать инкапсуляцию. Мы уже разобрали что такое абстракция.

💬 Когда абстракция нас покидает, на помощь приходит инкапсуляция. Абстракция говорит: «Вы можете рассмотреть объект с общей точки зрения». Инкапсуляция добавляет: «Более того, вы не можете рассмотреть объект с иной точки зрения».

Продолжим нашу аналогию: инкапсуляция позволяет вам смотреть на дом, но не дает подойти достаточно близко, чтобы узнать, из чего сделана дверь. Инкапсуляция позволяет вам знать о существовании двери, о том, открыта она или заперта, но при этом вы не можете узнать, из чего она сделана (из дерева, стекловолокна, стали или другого материала), и уж никак не сможете рассмотреть отдельные волокна древесины.

Encapsulation picks up where abstraction leaves off. Abstraction says, "You're allowed to look at an object at a high level of detail." Encapsulation says, "Furthermore, you aren't allowed to look at an object at any other level of detail."

Continuing with the housing-materials analogy: encapsulation is a way of saying that you can look at the outside of the house but you can't get close enough to make out the door's details. You are allowed to know that there's a door, and you're allowed to know whether the door is open or closed, but you're not allowed to know whether the door is made of wood, fiberglass, steel, or some other material, and you're certainly not allowed to look at each individual wood fiber.
—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"

И о сокрытии информации:

💬 "Впервые сокрытие информации было представлено на суд общественности в 1972 г. Дэвидом Парнасом (David Parnas) в статье «On the Criteria to Be Used in Decomposing Systems Into Modules (О критериях, используемых при декомпозиции систем на модули)». С сокрытием информации тесно связана идея «секретов» — аспектов проектирования и реализации, которые разработчик ПО решает скрыть в каком- то месте от остальной части программы.

Information hiding first came to public attention in a paper published by David Parnas in 1972 called "On the Criteria to Be Used in Decomposing Systems Into Modules." Information hiding is characterized by the idea of "secrets," design and implementation decisions that a software developer hides in one place from the rest of a program."
—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"

Таким образом, в команде разработки, где хорошо понимают роль инкапсуляции в управлении сложностью, не может возникать причин, препятствующих использованию ООП в пользу процедурной парадигмы. Обратите внимание, я не говорю о том, что нельзя писать хороших программ без использования ООП, и Niklaus Wirt поясняет почему так.

Целью данного цикла постов является антикризиная архитектура, поэтому, сейчас мы не будем погружаться в подробности истории зарождения OOP, тем более, что на эту тему уже был цикл постов. В контексте нашей цели интересно только то, каким образом OOP может способствовать управлению существенной сложностью. Обратите внимание, что цитаты из "The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr. взяты из главы ""No Silver Bullet" Refired", которая является продолжением известной его статьи "No Silver Bullet - Essence and Accident in Software Engineering" by Frederick P. Brooks, Jr.

Иными словами, эти цитаты имеют непосредственное отношение к управлению существенной сложностью.

Простым языком про абстракцию и инкапсуляцию писал Сергей Тепляков (который знаком лично с Bertrand Meyer) в статье "О дружбе значимых типов с ООП":

💬 Абстракция позволяет выделить существенные аспекты поведения, а инкапсуляция является тем инструментом, который позволяет спрятать ненужные подробности и детали реализации с глаз долой.

Далее я приведу формальное определение от Grady Booch, посколько именно его определения значительным образом повлияли на современное OOP.

💬 "Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior.

Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51].
Encapsulation hides the details of the implementation of an object. Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant. To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data but depend only on a schema that denotes the data’s logical view [52]. In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction.

“For abstraction to work, implementations must be encapsulated” [53]. In practice, this means that each class must have two parts: an interface and an implementation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.

To summarize, we define encapsulation as follows:

Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.

Britton and Parnas call these encapsulated elements the “secrets” of an abstraction [54].

<...>

Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity. Thus, encapsulation cannot stop a developer from doing stupid things; as Stroustrup points out, “Hiding is for the prevention of accidents, not the prevention of fraud” [56]. Of course, no programming language prevents a human from literally seeing the implementation of a class, although an operating system might deny access to a particular file that contains the implementation of a class.

-- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

Смотрите так же статьи в wiki by Ward Cunningham:
- https://wiki.c2.com/?EncapsulationDefinition

- https://wiki.c2.com/?EncapsulationIsNotInformationHiding

- https://wiki.c2.com/?InformationHiding

Обратите внимание, что текст по второй ссылке прямо противоречит статье в Википедии (причем, русскоязычный вариант статьи противоречит англоязычному - в одном варианте свойством языка является инкапсуляция, а в другом - сокрытие), поэтому я стараюсь избегать ссылок на Википедию.

Обратимся к первоисточнику термина "сокрытие информации" - к статье "On the Criteria to Be Used in Decomposing Systems Into Modules." by David Parnas:

💬 Information-hiding objects can be created in any language; my first experiments used primitive versions of FORTRAN.

Это противоречит англоязычной версии статьи Википедии о том, что сокрытие информации является свойством ЯП.

💬 When it is applied properly it is usually successful. Abstractions such as Unix pipes, postnoscript or X-win-dows achieve the goal of allowing several implementations of the same interface. However, although the principle was published 30 years ago, today’s software is full of places where information is not hidden, interfaces are complex, and changes are unreasonably difficult.

💬 While the basic idea is to hide information that is likely to change, one can often profit by hiding other information as well because it allows the re-use of algorithms or the use of more efficient algorithms.

Здесь мы видим цель сокрытия информации - упростить изменение программы путем управления Coupling, т.е. относится к области конструкции с точки зрения дихотомии функции и конструкции.

Инкапсуляция же отделяет конструкцию от функции. Она защищает интерфейс, который экспонирует поведение, т.е. функцию.

Мы разбиваем систему на компоненты, чтобы управлять сложностью, и на модули - чтобы управлять измением системы.

💬 The terms "module" and "component" are often used interchangeably, which causes confusion. As I mentioned earlier, any system is composed of components. Therefore, a module is a component. However, not every component is a module. To design a flexible system it’s not enough to decompose a system into an arbitrary set of components. Instead, a modular design should enable you to alter the system by combining, reconfiguring, or replacing its components — its modules.
-- "Balancing Coupling in Software Design: Universal design principles for architecting modular software systems" by Vlad Khononov

В качестве примера модуля Vlad приводит кубик конструктора Lego.

О том, что всякий модуль есть компонент, можно подискутировать по поводу примера с ножницами, но выделим главное: модуль - это о конструкции, компонет - о функции.

Таким образом, отличие между инкапсуляцией и сокрытием информации такое же, как между DIP и DI - второе является способом достижения первого.

💬 Encapsulation is most often achieved through information hiding (not just data hiding).
-- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

💬 InformationHiding should inform the way you encapsulate things
-- https://wiki.c2.com/?EncapsulationIsNotInformationHiding

В контексте управления существенной сложностью имеет значение именно инкапсуляция, поскольку она обеспечивает целостность инвариантов доменных моделей (модель - есть абстракция). Не важно, насколько быстро можно изменить программу, которая делает не то, что нужно.

💬 Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns.
-- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

Определение encapsulation от автора OO-парадигмы (не путать с автором термина OOP):

💬 Encapsulation means that access to the implementation part of a module is not possible from outside the module, i.e. the implementation of a module is hidden. This means that the usage of a module cannot depend upon internal details of its implementation, and thus it is possible to change the implementation of a module without affecting its usage.
-- "Object-Oriented Programming in the BETA Programming Language" by Ole Lehrmann Madsen, Birger Møller-Pedersen, Kristen Nygaard

Ну и формальное определение абстракции:

💬 Abstraction is one of the fundamental ways that we as humans cope with complexity. Dahl, Dijkstra, and Hoare suggest that “abstraction arises from a recognition of similarities between certain objects, situations, or processes in the real world, and the decision to concentrate upon these similarities and to ignore for the time being the differences” [42]. Shaw defines an abstraction as “a simplified denoscription, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment, immaterial or diversionary” [43]. Berzins, Gray, and Naumann recommend that “a concept qualifies as an abstraction only if it can be described, understood, and analyzed independently of the mechanism that will eventually be used to realize it” [44]. Combining these different viewpoints, we define an abstraction as follows:

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

An abstraction focuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation. Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46]. We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction.

-- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

В какой-то одной парадигме реализовывать систему может оказаться трудно, поэтому и был создан принцип CQS, позволяющий использовать преимущества обоих парадигм, как OOP, так и FP, - эта тема уже затрагивалась:
https://news.1rj.ru/str/emacsway_log/265

Был вопрос о том, как выглядят доменные модели в функциональной парадигме:
- https://github.com/swlaschin/DomainModelingMadeFunctional

- https://github.com/swlaschin/Railway-Oriented-Programming-Example

- https://github.com/swlaschin/RailwayOrientedProgramming

Ряд других примеров для курсов и воркшопов:
- https://github.com/swlaschin?tab=repositories

На Idris:
- https://github.com/andorp/order-taking

💬 Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении. Коггинс коворит:
«Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.» Рисковать реальными начальными деньгами ради предполагаемых, но неопределенных прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий.

The benefits, which I think are real and not merely putative, occur all along the development cycle; but the big benefits pay off dur-ing successor building, extension, and maintenance activities.
Coggins says, "Object-oriented techniques will not make the first project development any faster, or the next one. The fifth one in that family will go blazingly fast." Betting real up-front money for the sake of projected but iffy benefits later is what investors do every day. In many program-ming organizations, however, it requires real managerial cour-age, a commodity much scarcer than technical competence or administrative proficiency. I believe the extreme degree of cost front-loading and benefit back-loading is the largest single factor slowing the adoption of O-O techniques.

—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

Чем интересна эта фраза? Она утверждает, что источник кризиса в архитектуре, например, в результате применения Anemic Domain Model, может лежать в управленческой плоскости.

P.S.: Лично мне обретать свой первый DDD опыт приходилось в личное время.

На данном этапе у нас должны получиться следующие архитектурные артефакты:

1. Диаграммы трассировки требований.

Я использую Motivation View Points.

2. EventStorming диаграммы.

Я использую "C.1.10. Business Process Cooperation Viewpoint".

Подробнее здесь.

Шпаргалки по EventStorming здесь.

3. Context Map.

Я делаю как в "Model used by Jean-Baptiste Sarrodie for presentation "Enterprise Architecture Modelling with ArchiMate in an Agile at Scale Programme" (демонстрационная модель от автора OpenSource среды проектирования Archi).

Но есть и другие инструменты, перечисленные здесь.

Кстати, в тему обсуждения, доклад Сергея Баранова о восстановлении знаний об архитектуре системы:

Доклад
- https://www.youtube.com/live/4SEe2bx7090

Презентация
- https://news.1rj.ru/str/microservices_arch/531

Оказывается, в Archi вполне нормально можно вести бэклог разработки (используя Canvas).

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/
Просто прекрасная статья о сложностях GraphQL vs REST

Не перестаю удивляться народной мудрости. Галера - очень меткая (хотя и сатирическая) метафора для ИТ-проекта.

Гребцам нужно догрести из пункта А в пункт Б.

Представим, что конструкция дала течь. Обратите внимание, что по отношению к главному инструменту управления сложностью, абстракции, применяют такой же термин - "протекание". А все, что протекает, может потонуть. В чем может потонуть абстракция? В сложности (нерелевантных деталей), где "плавучесть" абстракции ограничена возможностями краткосрочной памяти человека.

Итак, конструкция протекает, наполняется водой (сложностью). Судно погружается, сила сопротивления движению растет. Если не предпринять меры по борьбе за живучесть судна, то сила тяжести превзойдет силу плавучести (правильней было бы сказать - выталкивания, гидростатическую подъемную силу).

То же самое происходит и с рентабельностью проекта.

И как показывает статистика, затопление происходит обычно в геометрической прогрессии.

Для борьбы за живучесть судна были придуманы водонепроницаемые переборки, которые позволяют остановить затопление судна (как и Bounded Context).

Но на галерах таких переборок может не быть. И вот команда стоит перед выбором - грести или спасать судно? Проблема в том, что с верхней палубы не видно того, что в трюмах воды по уши. И погружение судна в воду не так уж и заметно сверху - никто ведь не замерял осадку. И, кажется, что достаточно просто расчехлить плеть, чтоб заставить гребцов грести быстрее.

Чтобы восстановить скорость, нужно освободить судно от накопившейся сложности, а еще лучше - возвести водонепроницаемые переборки. Это означает потерять ход. Но восстановить скорость. Но это неточно. Можно и не восстановить. А вдруг не сумеют? Точно, весло так и не починили. А вдруг и нет никакой течи? А вдруг не из-за течи падение хода? А так хоть какой-то ход есть... Кажется, вон тот гребец в углу стал медленней грести. Или не стал? Замеров-то нет. Стал, вон другие галеры вырвались вперед. Точно. Ага. Нужно таки расчехлить плеть.

А может тот гребец прав, и все дело в течи? Нет, течь грести не умеет. Причем здесь течь? Где вёсла, а где эта мифическая течь... Все дело в том, кто гребёт. Точно. А про течь они все придумали. Хотят в трюм заманить. Только положи им палец в рот, ага, щас.. Некогда фигней заниматься, грести надо...

"Design and Reality: Essays on Software Design" by Mathias Verraes & Rebecca Wirfs-Brock
https://leanpub.com/design-and-reality

https://ru.singlelogin.re/book/24377478/a4e2de/design-and-reality-essays-on-software-design.html (уже устарела немного, правда).

Топ-3 задач, на которые ушло больше всего времени у Product Owners: "встречи, налаживание процессов и планирование".

При этом 17% столкнулись со сложностью "Взаимодействия с другими командами", т.е. проблемой Брукса. Встречи отнимают невероятно много ресурсов. Большинство продактов тратят на них от 40% своего рабочего времени.

А 27% столкнулись со сложностью в "бюрократии и политикой в компаниях".

При этом 23% опрошенных еще и занимается рабочими задачами в выходные.

Лишь 6% продактов уверены, что не сталкивались с признаками выгорания.

Для остальных "Работа в условиях большой нагрузки и выгорания " - главная проблема.

Общий вывод. Проблемы с точностью планирования, межкомандной коммуникативной нагрузкой, внутрикомандной когнитивной нагрузкой, сложность погружения в устройство продукта и предметную область, - являются отражением архитектурных проблем, и, прежде всего, функциональной (компонентной) декомпозиции системы.

А то, что каждый четвертый имел сложности с такими моментами, как "Бюрократия и политика в компаниях" и "Изменение процессов и продуктовой культуры в компании", отражает уже проблемы управленческие.

Обращает на себя внимание то, что среди главных проблем перечислены такие проблемы, как "большая нагрузка" и "планирование". Между этими проблемами есть связь, т.к. нагрузка является результатом планирования. Иными словами, качество решения второй проблемы является источником первой проблемы. А качество решения второй проблемы отражает архитектурное здоровье системы - чем оно ниже, тем хуже прогнозируемость планирования.

Источник:
https://devcrowd.ru/pm24/

Thanks to @nikitapinchuk

В целом опрос коррелирует с моим опросом. Общий вывод которого таков, что каждый четвертый доволен условиями работы лишь потому, что сам их создал себе. И только каждому двадцатому повезло попасть в благоприятную среду, созданную другими.