We accept that our understanding of our work evolves. I asked, how (when) do you know what you should have done? Of course I was thinking about refactoring of code that was once right but not now.
From a conversation in the Lean Coffee Federation.
I'm wondering, how can we sense with some confidence when the world has shifted enough that it is worth thinking through past decisions.
My question was misunderstood. Dose the word "should" imply that I made a mistake and want to correct it? No, this was not my intention.
This is the same way that my notion of technical debt is misunderstood. I argue that assuming debt is a sound business strategy and should be planned for else paying back principle turns onerous. youtube (5 min)
Oh, now we know what we should have done.
This happens on all programming projects of any substance. This happens whether one prepares for change or not. But does this happen at convenient times or with sufficient clarity?
My question was really about what we can do to become sensitive to refactoring opportunities.
We could hold retrospectives at regular intervals. These tend to be about team and process. They could also include a frank reassessment of how a codebase reflects a team's current understanding of its purpose.
We could measure the downslope of velocity that one would expect from mounting technical debt. This assumes consistency of story units. This transfers one measurement problem to another.
We could survey team members and ask them if they feel productive. I liked to ask, what percentage of your week are you grappling with issues that you can explain to the customer and know that they would be glad that you are doing this work on their behalf?
We could maintain a database of alternative implementations and reevaluate the applicability of each at regular intervals. Presumably some would rise to a cost/benefit threshold.
We could speculatively implement alternative architectures and expect them to coexist in the codebase. (Polymorphism makes this possible.) The small perturbations sometimes called "bit rot" would favor the better and it would bloom.
We could expect most of our engineers to maintain a broad knowledge of our modules and their interactions and look to them to feel the pain when they are no longer working well.
I have seen all of these methods work. However, I have not seen agreed upon policy regarding which and how much of each an enterprise intends to use to protect its software investments.
I coined the debt metaphor to emphasize the need for management policy and to explain the nature of the responsibility I had been excepting for managing debt in our own codebase. paper
I haven't seen much improvement on the casual methods I have used. There is, however, an emerging industry that is focusing on poorly written or woefully obsolete codes as if this is the center of the problem.
I don't believe this approach is going to lead to a better place because there is no sensitivity to opportunity in any work going forward.