Lately I bought a book published by a ThoughWorks employee: “Fundamentals of Software Architecture: An Engineering Approach”.
I praise ThoughWorks and all the companies out there that dedicate time and effort to distribute knowledge, however it is collected, however it is shared, inside the company and outside.
I praise them because, in my decades long career in IT in Spain, I’ve yet to work for such a company. Each one of the companies I worked for didn’t have any implementation of information sharing, except maybe for an internal basic wiki, with mostly stale content.
Did you know that Martin Fowler works at ThoughWorks? His writings, at the same time professional and accessible, innovative and systematizing, fundamental in essence, made me expect a comparable level of excellence for this FSA book.
Instead, the standards are quite low here. I’m about to start studying the fourth chapter, but I already found something so bad that pushed me to write this post.
First, I can summarize the first two chapters like this: “Be a professional IT specialist and apply common sense.” Not really fundamental, nor surprising stuff, but the worst thing is that the authors needed 35 pages for telling me that.
Second, the Modularity chapter is an anthology of misfires.
The issue with module
The authors start by recognizing how difficult it is to find a usable definition of “module” in IT, so much so that they dedicate the first section of the chapter to define it.
Leaving aside the fact that the chosen definition (albeit appearing in the first paragraph) is blended with discursive text instead of being extracted and framed as we are used to see in foundational books, I start having doubts about whether I match the target readership of this book or not.
In 2020+ there is really no IT professional on Earth that doesn’t know what a module is. Anyway, it surely makes sense to define one of the fundamental concepts of software architecture in a book about Software Architecture. Why not be rigorous then?
The authors just say that a module is a “logical grouping of related code” and explain it by enumerating its many implementations in programming languages. I’m not comfortable with this definition because I think they missed a crucial point.
A module is a logical grouping of related code WITH A GIVEN NAME.
Forgetting to mention the name here, which is basically the very essence of the abstraction a module provides, is a huge mistake.
Only after you give a name to a logical grouping of related code, that code becomes a module. And only because of the name, you can ask yourself how much the code is cohesive.
Other issues
Cohesion
In this section, the authors start with a good definition of cohesion, but soon after, when defining each of the different types, they say “two modules”, when they really mean “two parts of a module”, which is quite confusing.
Coupling
In this section, the authors start with the definitions of afferent and efferent coupling, which first appeared in the book “Structured Design: Fundamentals of a Discipline of Computer Program and System Design”.
I didn’t have a chance to read that book, but the authors of the FSA book did not explain the subject clearly, nor did the authors of the related Wikipedia pages: Software package metrics and Efferent coupling, which almost contradict each other.
In the FSA book the authors say that
- Afferent is the number of incoming connections to a code artifact
- Efferent is the number of outgoing connections to other code artifacts
The Wikipedia pages are much better at this, because dependency makes a lot more sense than connection. In the first page, the Wikipedia authors say that
- Afferent is the number of elements in other modules that depend on a module
- Efferent is the number of elements in other modules that a module depends on
However, in the second page they also say that
- Efferent is the number of elements in a module that depend on other modules
which is quite different a number from the previous definition, and possibly wrong.
Abstractness, Instability, and Distance from the Main Sequence
In this section, the authors start with a wrong definition of abstractness
- Abstractness = [Count of Abstract Elements] / [Count of Concrete Elements]
but, in the following section, they say
Note that both abstractness and instability are ratios, meaning that their result will always fall between 0 and 1.
which is right but contradicts their own definition.
In fact, the right definitions of abstractness is
- Abstractness = [Count of Abstract Elements] / [Count of All Elements]
Distance from the Main Sequence
In this section, the authors don’t give any reference to support the admittedly arbitrary statement that modules for which Abstractness == Stability are balanced and healthy, nor they say why these two would be competing concerns.
What I missed
This chapter on modularity is all but foundational.
The subject is presented along the historical point of view, which instead should have been collected into a separate section, appropriately called “If you ever wondered how this all came about”, which one could decide to skip.
Throughout the chapter there is a great deal of confusion on terms, again for historical reasons. For example, to the same end, the authors use functions, classes, packages, modules, components.
The principle of high quality modular architectures that is summarized by the sentence “strong cohesion, loose coupling” is never mentioned, not once. However it permeates almost every paragraph.
Types of cohesion, coupling, and connascence are enumerated and defined separately, again following existing literature. Really with no other reason than that, because they are basically the same concepts.
Cohesion
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
Coupling
Afferent
Efferent
Stamp
Control
External
Content / Pathological
Connascence
Name
Type
Meaning / Convention
Position
Algorithm
Execution
Timing
Values
Identity
How refreshing would have been to see only one enumeration, with no duplicates, with all the types defined in a generic but usable fashion.
All the formulas for assigning some meaningful numerical value to a system of modules occupy a big portion of the chapter. However, the authors don’t justify any, and state that they fail their purpose to mean anything. So why, why on Earth are they central to the chapter instead of being collected in an appendix at most?
Quite disappointing that a book about architecture doesn’t show much of it in the organization of the subject, at least in this initial chapter on modularity.
Crossing fingers for the rest of the book.
