What our brains can teach us about software engineering

It's simple

Aprendendo a aprender

Recentemente, ouvi a entrevista do Fabio Akita no DEVNAESTRADA e fiquei bastante admirado com a sua história, seu conhecimento e sua visão. Em particular, achei especialmente pertinentes os comentários dele sobre a necessidade de aprendermos a aprender (isto é, de cultivarmos uma mentalidade de estudo, crescimento e evolução constantes) e sobre o papel do verdadeiro engenheiro, que é o de resolver problemas, não o de se tornar um defensor de ferramentas (algo na mesma linha do que comentei sobre trade-offs). Vale a pena escutá-lo relatando sua trajetória e compreender como ele aplica essas filosofias ao seu método de trabalho.

Top-down design

The issues we have discussed so far lead to an inescapable conclusion. The package structure cannot be designed from the top down. This means that it is not one of the first things about the system that is designed. Indeed, it seems that it evolves as the system grows and changes.

You may find this to be counterintuitive. We have come to expect that large-grained decompositions, like packages, are also high-level functional decompositions. When we see a large-grained grouping like a package dependency structure, we feel that the packages ought to somehow represent the functions of the system. Yet this do not seem to be an attribute of package dependency diagrams.

In fact, package dependency diagrams have very little to do with describing the function of the application. Instead, they are a map to the buildability of the application. This is why they aren't designed at the start of the project. There is no software to build, and so there is no need for a build map. But as more and more classes accumulate in the early stages of the implementation and design, there is a growing need to manage the dependencies so that the project can be developed without the morning-after syndrome. Moreover, we want to keep changes as localized as possible, so we start paying attention to the SRP and CCP and collocate classes that are likely to change together.

As the application continues to grow, we start becoming concerned about creating reusable elements. Thus, the CRP begins to dictate the composition of packages. Finally, as cycles appear, the ADP is applied and the package dependency graph jitters and grows.

If we were try to design the package dependency structure before we had designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create packages that produce dependency cycles. Thus, the package dependency structure grows and evolves with the logical design of the system.

Robert C. Martin, "Principles of Package Design", in Agile Software
Development: Principles, Patterns, and Practices, 260-261.