Quotes From The Book - part 1 - Tidy First?¶
Over the past two years I had the chance to read a bunch of data-related books on the O'Reilly learning platform: what follows is a collection of quotes from "Tidy First?" by Kent Beck that captured my attention or hit hard because they were highly relatable.
Tidy First?¶
3. Normalize Symmetries¶
As a reader, you expect that difference means difference.
6. Cohesion Order¶
Sometimes the increased clarity from slightly better cohesion unlocks whatever is blocking you from decoupling. Sometimes better cohesion helps you live with the coupling.
12. Extract Helper¶
Frequently you’ll find yourself wanting to use your new helper again hours or even minutes after you’ve created it. Interfaces become tools for thinking about problems.
13. One Pile¶
The biggest cost of code is the cost of reading and understanding it, not the cost of writing it. Tidy first has a bias toward lots of little pieces, both theoretically, to increase cohesion as a path to reducing coupling, and practically, to reduce the amount of detail that needs to be held in your head at any one time.
16. Separate Tidying¶
Chunking statements leads to explaining helpers leads to an easier time making behavior changes. Now programming is more like chess, and you can guess how the game will play out several moves (or sequences) ahead
18. Batch Sizes¶
If we want to reduce the cost of tidying, thus increasing tidying and reducing the cost of making behavior changes, then we can reduce the cost of review
20. Getting Untangled¶
The answer, as always, is because you are not just instructing a computer, you are explaining your intentions for the computer to other people. The shortest path to instructing the computer is not an interesting end goal.
21. First, After, Later, Never¶
Finally, tidying later just feels good. Software development is a human process. We are humans with human needs. Sometimes I just don’t have the energy to tackle a new feature, but I want to work. Picking an item off the Fun List and tidying it brings me joy. Don’t underestimate how much better you are as a programmer when you’re happy.
What would you do if you temporarily, provisionally believed that there was enough time to do your work?
23. Structure & Behavior¶
This is the secret it took me decades to absorb. I didn’t have to change the behavior of my system to make it more valuable. As soon as I added to the options of what it could do next, I had already made money.
24. Economics: Time Value & Optionality¶
In a chaotic situation, options are better than things, so create options in the face of uncertainty.
25. A Dollar Today > A Dollar Tomorrow¶
If we can implement a behavior change that makes us money now and tidy after, we make money sooner and spend money later.
26. Options¶
Software design is preparation for change; change of behavior. The behavior changes we could make next are the potatoes from the story. Design we do today is the premium we pay for the “option” of “buying” the behavior change tomorrow.
“What behavior can I implement next?” is more valuable the more the behaviors in that portfolio are valuable.
“What behavior can I implement next?” is more valuable the more behaviors are in the portfolio.
I thought I was getting paid for what I had done (as per the previous chapter). I wasn’t. I was mostly getting paid for what I could do next.
29. Coupling¶
Sometimes when you’re staring at a messy change, it’s coupling that’s harshing your mellow: “But if I change this, then I’ll have to change all those too.” Messy. Take a minute to go through the list of tidyings and see which of them would reduce coupling.
Coupling drives the cost of software.
30. Constantine’s Equivalence¶
the cost of software is approximately equal to the coupling
the cost of change is approximately equal to the cost of the big changes
the cost of software is approximately equal to the cost of changing it
the goal of software design is to minimize the cost of software
If we apply our creativity, we can release value-creating software after only a few percent of its eventual development cost. It’s in everyone’s best interest to do so. The sooner we get feedback from real usage, the less time/money/opportunity we spend on behavior that doesn’t matter.
33. Conclusion¶
Most important, though, is you. Will tidying bring peace, satisfaction, and joy to your programming? Maybe some. This is important because if you are your best self, you are a better programmer. You can’t be your best self if you’re always rushing, if you’re always changing code that’s painful to change.