Ford Motor Company frequently updates their factories for each new model. In fact, a factory will completely cease production whilst updates take place – sometimes for weeks at a time. These are planned, scheduled, detailed, negotiated, etc. as it is a very costly event.
Not performing these shutdowns is even more costly, as Ford would quickly go out of business.
Software people tend to have a different approach: we think updates can be done in place while delivering business value. Shutdowns are not what we do.
So then, how well do we do it? Do you really think you can refactor your object-oriented database interface into a NoSQL database via a series of 2-week iterations? What percentage of the team will work on the refactoring? How will the integration between the final refactored branch be handled? How are other new features & defects being integrated into the NoSQL branch? How are you handling turnover during this (better to pretend it won’t happen, huh?) refactoring effort? What percentage of your team has the intellectual bandwidth to manage this much concurrent change? Do you have it? Does your team really think they understand the depth & breadth of the change? How do they have the expertise to affirm that?
Let’s consider a formal “shutdown” to do some really heavy lifting.
If the team stopped delivering new features for 4 or 6 weeks would the customers really care? Even notice? Are your customers so demanding that frequent updates are a must-have? Have you ever discussed this with them? Would the team perform better with a simple definition of success? (The refactoring.) Would bugs be easier to triage & resolve? Wouldn’t it be great for developers, testers, documentation, etc to be able to have a single focused discussion(s)? Would progress be easier to track & evaluate? Would your confidence be higher at each step along the way? Would everyone be glad to have a definitive start/stop?
Perhaps shutdowns have some consideration after all.