Here we have the economic tug-of-war that makes “tidy first?” such an interesting question:
Discounted cash flow tells us to make money sooner with greater likelihood and spend money later with less likelihood. Don’t tidy first. That’s spending money sooner and earning money later. Maybe don’t even tidy after or later.
Options tell us to spend money now to make more money later (even if we don’t currently know exactly how). Absolutely tidy first (when it creates options). Tidy after and later too.
Tidy first? Yes. And also no.
Now, there are times to tidy first for sure. When:
cost(tidying) + cost(behavior change after tidying) < cost(behavior change without tidying)
then absolutely tidy first. It’s still easy to get carried away and tidy too much, but set and maintain boundaries for how far you’ll go and you’ll be fine.
The more fraught situations occur when:
cost(tidying) + cost(behavior change after tidying) > cost(behavior change without tidying)
You might still want to tidy first, even though short-term economics discourage you. You may be implementing a series of behavior changes, all of which benefit from the tidying. Amortizing the cost of the tidying across all the changes might make sense, even discounting the cash flows.
Tidying first may make economic sense in spite of discounted cash flows if the value of the options created is greater than the value lost by spending money sooner and with certainty. We are firmly in the land of judgment here. Your sniffer might tell you, “There’s more good stuff here, but I need to tidy to be able to see it.” That may be good enough evidence for more tidying.
Or, since software design is an exercise in human relationships and we’re talking about our relationship with ourself at the scale of tidying, you might tidy first just because it makes the subsequent behavior changes more pleasant. A little bit of this “tidying as self-care” is justified. Just recognize that you are going counter to your economic incentives.
At the scale of tidying—minutes to hours—we can’t (and shouldn’t try to) precisely calculate the economics of our tidying. We are exercising two important forms of judgment, practicing for bigger things later:
Getting used to being aware of the incentives affecting the timing and scope of software design (“I want to spend more time designing and I’m getting pushback. What’s going on?”)
Practicing on ourselves the relationship skills that we will later be using with our direct colleagues, and then our more distant colleagues
Once we raise the stakes, where the survival and thrival of a product is on the line, we’ll be glad of a gut sense of when and how to design and when not to design.