false incrementalism
I've come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces.
…
Beware the false incrementalism!
False incrementalism is breaking a large change up into a set of small steps, but where none of those steps generate any value on their own.
…
if after each increment, an Important Person were to ask your team to drop the project right at that moment, would the business have seen some value? That is the gold standard.
…
We made an early decision to: a) rewrite all the existing reports before writing new ones, and b) rewrite each report completely, push it through to production, migrate any existing data for that report, and switch all our customers over. And only then move on to the next report.
Here's how that completely saved us: 3 months into a rewrite which we had estimated would take 3-5 months, we had completely converted a single report. Because we had focused on getting all the way through to production, and on migrating all the old data, we had been forced to face up to how complex the overall process was going to be. We sat down, and produced a new estimate: it would take more like 8 months to finish everything up, and get fully off SQLServer.
…
…one interesting piece of value we generated early was simply a better understanding of how long the project was going to take. […] If we hadn't pushed a single report all the way through, we would likely have had, 3-4 months in, a whole bunch of data (for all reports) in some partially built new system, and no better understanding of the full challenge of cutting even one report over.
…
One of the reasons people bail on incrementalism is that they realize that, to make it work, there's going to be an extended period where every update to a piece of data has to go to both systems (old and new).
…
Here's what I'm going to say: always insert that dual-write layer. Always . It's a minor, generally somewhat fixed cost that buys you an incredible amount of insurance.
… Abandoning the Project Should Always Be on the Table …
if you have any uncertainty about how long it's going to take, sequence your work to reduce that uncertainty right away, and give people some "finished" thing that will let them walk away.
…
you're going to run your migrations over and over to get them right. Plus, you're converting and summing up and copying over data, so you really, really want some unit tests to find any errors you can early on
"data" is, to a first approximation, "a bunch of opaque numbers which don't mean anything to you, but which people will be super pissed off about if they're wrong"
treat your migration code as a first class citizen. It will save you a lot of time in the long run.
…
f you learn to approach your rewrites with this kind of ferocious, incremental discipline, you can tackle incredibly hard problems without fear.