Tidy First?, reflect next: chapter 6
Kent Beck's "Tidy First?" applications in my software development
This is the sixth iteration of Tidy First?, reflect next. A brief recap so far: I worked with Kent and learned a lot. He recently wrote Tidy First?: a book about tidying, but also when do to it. I’m studying it as applied to my recent work in bioinformatics. [GitHub].
Previously: Intro & Chapter 1; Chapter 2; Chapter 3; Chapter 4; Chapter 5.
Chapter 6: Cohesion order
Cohesion order is the big sibling to the previous chapter’s reading order: it rearranges the code altogether, not just one file. If things need to change together then place them together.
Quick vocabulary note:
Cohesion is a “spatial” concept of being together, relating to a file, a folder of files, a module of code, a codebase, or some other concept of location. There are many reasons why code could be colocated: implementing some bigger functionality together; relating to the same category of task (e.g. user input); handling the same data; and so on. The Cohesion Wikipedia article has more examples.
Coupling is a "logical” concept of being linked (as opposed to simply in the same spot). If two functions are coupled, then one’s behavior affects the other and possibly vice-versa. For instance, a function’s default parameter value is coupled to every call site that doesn’t specify that parameter. Changing the default requires changing all those call sites.
In general, “too much” cohesion is bad because it’s putting code together for no reason, increasing the cognitive burden of understanding the software pieces. And “too much” coupling is bad because changes are hard to isolate, again increasing the burden of wrangling the software.
Kent’s problem statement is discovering coupling across code that is not cohered: a change requires modifications across the codebase. There’s a few advantages to this. First, it reinforces or even simply surfaces the coupling by putting the things together. Next, it makes it easier to understand the behavior changes because we’re not hunting all over the code. And third, perhaps most importantly for the long run, that proximity can generate ideas to snip the coupling in the first place.
As usual, this tidying is so valuable that I’ve integrated it into my method. This is a good example: deepcell-imaging PR#282 Add qupath runner. The first change introduces new code that mostly duplicated existing code, & proactively coheres it. We knew the duplication was undesirable (coupling things like network configuration across the jobs that just want the “normal” settings), and we knew we’d likely refactor to simplify. But we weren’t yet sure what that meant.
Once the cohesion was introduced (albeit by creating not moving), it became quite clear where the commonalities were. So in the second commit, we did that. Even so, we knew we weren’t done– but, as Kent says, sometimes the cohesion helps you live with the coupling until you figure it out.
We indeed figured it out later: deepcell-imaging PR#315 Implement segment and measure job. It was good to wait until then because we had yet more cohered examples, so patterns began to emerge that were only speculative before.
This is the sixth in a series of posts reflecting on the book Tidy First? by Kent Beck. See also: Chapter 1, Chapter 2, Chapter 3, Chapter 4; Chapter 5. Follow Kent’s ongoing work here:
The series introduction:
About Binary Alchemy
Binary Alchemy is the art of software engineering: part programming, part philosophy. Software melds the elegance of mathematics with the unyielding realities of zeroes and ones. Software is ethereal, less constrained than materials in its ability to metamorphose (or metastasize).
I wrote my first line of code in 1989. I have decades of experience building, operating, and re-building software spanning from MS-DOS to GCP, AWS, and Azure. ️⚙️ I’ve worked with startups and large enterprises, including Google, Microsoft, Square aka Block, Gusto, and others.
I provide software & cloud architecture consulting services. Learn more: RedwoodConsulting.io