Let’s go back to the beginning. You are tidying to make future changes
to the behavior of the system easier. You are making future behavior
changes easier because you’re worth it (we’ll get into the economics
later, if anyone objects). What are we talking about here? A brief
moment, then back to the slog? Hour upon hour of blissful
tidying?
Part of the art of managing tidying is managing the rhythm of it. In the
previous chapter, we saw this image (Figure 19-1), encouraging smaller batches of tidying.
Figure 19-1. Structure changes batched together or separately
How much time is represented in one of those successions of structure
changes followed by a behavior change?
Well, software design is fractal, so it could be any time scale. For the purposes of this book, however, we are talking about one scale of
software design: software design with personal impact. For that, we are
talking about minutes, up to an hour. More than an hour of tidying at a
time before making a behavior change likely means you’ve lost track of
the minimum set of structure changes needed to enable your desired
behavior change.
Another possibility, though, is that the code is in such a mess that you can
profitably tidy for hours before making a behavior change. If this is
true, it won’t be true for long. Software design has a strong “pave the
path” tendency.
If you haven’t heard the story, ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
