Tidying Versus Sooner
I promised I would put together the posts on Better/Sooner/Cheaper/More with the actual topic of this mailing list, Tidy First? And here I am delivering.
To reiterate, software product development should mostly be managed through scope, not deadlines or budget. That doesn’t mean time & budget don’t matter, just that you aren’t generally going to get more of what you want by tightening the screws on time or money.
However, designing software invests time, time you could be using to do other things. When do want to invest that time in software design? When don’t we?
This question will become more relevant with the follow-on books, where we talk about software design at larger scopes & over longer timeframes. Part of the beauty of starting with tidying is that the timeframes are so short that there’s not much need to discuss whether we tidy or not (it will still come up, but less).
Let’s start the discussion with the cost of delay. The exchange rate from minutes to dollars varies wildly. Saving a demo during a critical sales call can mean the difference between company survival & ummm not survival. Those minutes are worth millions, maybe billions. Another example of high cost of delay is a production incident. Seconds mean dollars, maybe even survival.
In such extreme scenarios, don’t tidy first unless you have no alternative. Don’t tidy after until the price of minutes drops back to normal. Changing the behavior of the system is by far the priority. If it’s a little easier or harder to change, 🤷.
How about situations where the cost of delay is high, but not obscene? Say you have to get a demo ready by the end of the week. Not having the features called for in the demo storyboard is expensive. Tidying first is still likely called for. Remember, we’re talking about minutes, maybe up to an hour, when we’re talking about tidying. That hour is unlikely to be difference between having a feature & not. It may even be a positive difference, enabling you to implement a feature that would have been out of reach without tidying.
For any less intense cost-of-delay situation, time & tidying don’t interfere. It’s still up to you to limit your tidying to tidying required to make the next behavior change. A week of tidying is nonsense, even a day. Remember, while we’re building a software design habit we’re keeping our design investments to innocuous little spurts (we’ll talk about how to manage larger scopes in the next book).
So, tidying versus sooner? Not a thing except in emergencies.
I've been trying to figure out how to push for and justify code cleanup at the startup I work at where there's immense pressure to deliver the next thing. There are areas of the codebase where we can all nod our heads and agree that it's difficult to work with and slows down development, but taking the next step to invest in cleanup or encourage engineers to think about tidying first (or even after) so building the next thing is easier has been difficult. I like the idea of price per minutes, it helps with thinking about how to structure the discussion and push on whether we are avoiding delay of tidying because that's what has become the culture versus a concrete risk.
On of he main goal of tidying is to avoid delays by reducing technical debt. So that it should be, as you said, only with a few exceptions from Tidy First.