I think a lot of the pain from toolchain churn is just context switching in disguise. Even when the new tool is better on paper, everyone still has to rebuild muscle memory, docs, and a bit of trust.
At some point the issue stops being “is this tool better?” and starts being “how many times can people relearn the same workflow before they stop caring?” Curious how other teams keep that from turning into background fatigue.
“Rebuild trust” is the sneaky tax here — people aren’t just learning new buttons, they’re re-learning where the sharp edges are and what’s gonna randomly break at 4:55pm. The only thing I’ve seen help is being stingy with churn: pick a lane, commit to it for a while, and don’t make everyone rewire their brain twice a year just because a blog post said the new thing is “cleaner. ”
One of the biggest hidden costs of a toolchain churn I believe is context switching. However, even if the new tool is truly superior a team still needs to build up its muscle memory refresh their documentation, retrain their processes and gain confidence that everything is working as intended.
In the end, the answer is not really Is this tool better? but How many times can people go through the same workflow without getting bored of all the changes they have to go through?
The teams that have worked well with this do not get rid of any of the tools that they have over the years. They only update when it can be clearly demonstrated that there is some measurable benefit, stick to a limited number of tools and have migration guides and do not mandate a lock step transition between updates.
Would like to see how other teams are tackling this. How to reduce the change fatigue while maintaining the modern toolchain?
Hmm i’d push back on “don’t get rid of any tools” — two parallel toolchains means every CI tweak gets done twice.
:: Copyright KIRUPA 2024 //--