Don't work aheadWorking ahead in software is a very risky thing to do, and is almost never a good idea.
Last week I posed situational question: How would you respond to someone seeking help managing a number of “refactoring stories”. Today I share another one of my many thoughts on the situation.
Our team is currently engaged in some refactoring stories, and I have a question about how to properly handle the size and placement of these tasks. We’ve created six stories specifically for this purpose, and they are currently being worked on in a local development environment. These stories won’t be implemented until the next version of the software, which we are not yet focused on.
The last sentence of the quote I find to be quite troubling.
Doing work slated for an upcoming release, when the current release isn’t even complete, poses a large number of problems. Perhaps especially when it’s refactoring work, as in this case.
- What if we never release the current version? Business needs could change. The company could pivot. The company could go out of business (especially if this is a startup). The effort to work ahead would be completely wasted.
- Or related, what if parts of the code that are refactored are deemed unnecessary for the next version, and are deleted? Again, an example of wasted effort.
- Where will this changed code live between now and the next version? In Lean parlance, this is called “inventory”, and it’s a form of waste.
- When it comes time to integrate these changes, who will do that work, including conflict resolution? And how will correctness be ensured?
- What if, after integration, problems are found? Who will fix them? What if the original developer has left the team, or forgotten why they did things a certain way?
I’m sure you can think of other risks that this working ahead approach brings on.
The bottom line is: Working ahead in software is a very risky thing to do, and is almost never a good idea.
What’s more, if this refactoring is actually useful, why not do it in the current version? That would address all of these risks, plus it would give the team the added benefit of working on a cleaner, tidier, refactored codebase immediately.
It's not valuable until the user can use it
Products or features not yet in front of the user are called "waste" in Lean.
Unless you enjoy the challenge of blind-folded piñata-style refactoring, write automated tests.