Tidy First?

Chapter 21. First, After, Later, Never

Let’s talk about the timing of tidying with respect to a behavior change in the system. Tidy first, then change the behavior? Change the behavior, then tidy? Or simply note messiness (in the sense that future behavior changes are going to be harder than they need to be), then come back later to tidy? Or, don’t tidy at all?

Never

Let’s start with the last one. As always, we need to examine the trade-offs involved in not tidying at all. When should we say, “Yes, this is a giant mess, and we consciously choose not to do anything about it”? The best reason is because we’re never going to change the behavior of the code ever, ever again.

I stated the condition like that because it’s rare that code truly never needs to have its behavior changed. However, it does happen. For truly static systems, “If it ain’t broke, don’t fix it” reasonably applies.

Later

Some folks think tidying later is pure fantasy, a unicorn, an honest politician. The mythological status of tidying later is used as justification for tidying too much now, whether that is before or after. I’m here to tell you that you really can tidy later. You may not like the prerequisite, though.

Is there enough time to do your work? I’m not asking whether you have plenty of time, because of course not. I’m not asking whether there’s more to do than you have time for, because of course there is. Ask yourself, “How would we work if we had enough time?” If the answer is wildly different from ...