I guess it depends on the tidying. Multi-step tidyings have noticeable troughs. E.g. "New Interface, Old Implementation" has one because there's an in-between state where you have code calling both the new and old interfaces.
In practice, the development workflow might matter more than the specific tidying. I find that a pull request workflow widens and deepens the trough of despair associated with structure changes. Waiting for approval and fixing merge conflicts both create delay - hence the trough is wider. Meanwhile, the human/computer system as a whole is in a worse state (one more version of the code that people have to hold in their heads) - hence deeper. I've often asked myself "is this really worth it" when I have to submit a PR for a refactoring.
New Interface/Old Implementation is a good example of Trough of Despair. The code's gotten worse but then it'll get better. I agree with the comment on blocking/async code reviews. I'd like teams to experiment with going straight to trunk with provably safe changes. But that's just me.
Love this. So true. I love the feeling when you're finally exiting the Trough of Despair, things "suddenly" start making sense, and the path becomes more clear 🙂.
I always try to do incremental steps if I can. Less chance of breaking things, and if they do break, easier to know what broke it.
There's an art to that slicing.
I very much like the emphasis on the steps size and their effect on the progress curve. Forcing myself to take very small steps improves 2 things:
* progress curve is steeper (but as more steps are taken it does not reflects immediately in things done more quickly)
* progress is safer (avoid the sub-optimal plateaus not reaching the desired goal).
Applicable to lots of context outside of software design.
Thanks Kent
So true. I read The Dip by Seth Godin over a decade ago and it profoundly changed how I thought about software design (and many other things).
Are tidyings immune to the trough of despair? Or do they just make it so small that it's hard to notice?
Go through the list & tell me what you think. Is there a moment "in the middle" where you think, "Why am I doing this?"
I guess it depends on the tidying. Multi-step tidyings have noticeable troughs. E.g. "New Interface, Old Implementation" has one because there's an in-between state where you have code calling both the new and old interfaces.
In practice, the development workflow might matter more than the specific tidying. I find that a pull request workflow widens and deepens the trough of despair associated with structure changes. Waiting for approval and fixing merge conflicts both create delay - hence the trough is wider. Meanwhile, the human/computer system as a whole is in a worse state (one more version of the code that people have to hold in their heads) - hence deeper. I've often asked myself "is this really worth it" when I have to submit a PR for a refactoring.
New Interface/Old Implementation is a good example of Trough of Despair. The code's gotten worse but then it'll get better. I agree with the comment on blocking/async code reviews. I'd like teams to experiment with going straight to trunk with provably safe changes. But that's just me.
Love this. So true. I love the feeling when you're finally exiting the Trough of Despair, things "suddenly" start making sense, and the path becomes more clear 🙂.