- Books
- Architecture
- Refactoring
I tend to forget the contents of books I read quickly, so I’m organizing the points I found important as a memorandum.
“Should we fix messy code as soon as we find it?” To this question, Kent Beck’s new book Tidy First? takes an empirical stance that engineers would find convincing (or perhaps disappointing): “Ultimately, it’s case-by-case.”
However, the highlight of this book is that it doesn’t stop thought there; it clearly presents criteria for “when and how to decide” from the perspective of cost.
Judgment During Task Execution
When adding features or fixing bugs, we always succumb to the temptation of “I want to fix this while I’m at it.” However, you must not mix functional changes (behavioral changes) with tidying (structural changes). It makes the intention of the PR unclear and makes reviewing difficult.
Therefore, when starting a task, you need to logically decide “Do it now, or do it later?” The book defines the criteria for this judgment as follows:
1. The Principle of Rewards (Cash Flow) First
“A dollar today is worth more than a dollar tomorrow.” If the reward (revenue or user value) gained by releasing that feature early is large, the correct answer is to “Tidy Later.”
Tidying first is an act of “paying the cost now.” If performing tidying delays the release and reduces the reward that could have been gained, that could be a decision lacking economic rationality.
2. Option Value and Cost Reduction
Conversely, if “the reward won’t change even if released now” or “the cost of change is too high as is,” you should “Tidy First.”
The true identity of what drives up software change costs is “Coupling.” Tidying first to loosen coupling can be described as an investment to purchase the “right (option) to make future changes cheaply and safely.” If this dramaticlly eases the implementation of the main task, you should do it without hesitation.
Formulas for Judgment
The wonderful thing about this book is that it expresses these judgments in the following formulas. As a STEM engineer, I am saved by this clear logic.
(1) Formula for Deciding Whether to Tidy First
If this inequality holds true, “Tidying First” is economically rational. However, do not forget the aforementioned “Principle of Rewards (Cash Flow) First.” Even if tidying is cheaper in terms of cost, if the value (time value) of releasing right away is overwhelmingly high, choosing “not to tidy” is also a correct answer.
(2) The Identity of Software Cost (Constantine’s Equivalence)
In other words, the only way to lower software costs is to tidy up and reduce “coupling” between elements.
“Cost calculation by formulas” and “Time value of cash flow.” Making decisions based on logic, not emotion. It is important to derive the “optimal solution” for each moment.
