Eventually all software shops have to get good at migrations. But they're very hard to get good at. We don't have good practices. — Lorin Hochstein
StaffEng: Interview with Lorin Hochstein podcast 
. This page is focusing on one of many great points Lorin shares in this podcast. And further supported by an example from Ward Cunningham.
The biggest obstacle to improving engineering in a software organization is carving out time to reflect. When you're stretched, when you don't have time to think about what happend, then you cannot make the most of those experiences.
For example...
24:55 Once an organization reaches a certain size migrations are gonna be happening all the time. It's not like "are you doing a migration?", but more like "how many migrations are happening?" Doing migrations has to become a core competency.
I don't know about you, but many times migrations end up being really painful. In my experience it is really rare for people to reflect on the migration. What happened? What did we think was going to happen? What did we learn from it? Usually, it's just "Okay. We're done. Let's move on."
One of the reasons we don't get better at migrations is that we don't spend the effort to understand or learn from the previous one. We don't make our systems better to make the next migration easier.
How do you justify this work to management? See Sell Resilience to Leadership
.
Ward Cunningham has a specific story which illustrates why organizations benefit from embracing change as a core skill.
Collective Ownership of Code and Text: A Conversation with Ward Cunningham, Part II
link
For example, in one project we eliminated the cost of a mistake with frequent releases. And we did it by building a fairly elaborate mechanism for database schema evolution. We'd release weekly and we'd do a schema change every week. We could make different schema changes for different customers in different orders, and have it all come together and be right in the end. And because we did it every week, after about six or eight weeks, we believed we could do it. We were never afraid to do it. Most people say, "Whatever you want to do, don't do schema evolution unless you really have to." And at the end of the project they say, "Oh my god, we really have to." So without ever doing it before, they say, "As long as we're going to do it, let's do all of it." They make a gigantic project, something they have no practice in. And what do you know? They get it wrong. By contrast, we do it every week. Do a little bit every week. We get really good at it. We're never afraid of it. It's never a problem.
So we erased a problem by not trying to erase the problem, by saying, "This is in the nature of what we do." It's really weird that it could be that simple. It's really more the approach of asking, "What do you want to be good at?" If you want to be good at it, find a way that you get to practice every day. If you practice every day there's no way you can help but be good. So, pick what you want to be good at. Well, you ought to be good at what you're afraid of. Then you'll stop being afraid of it.
.
To Kill It or Not Kill It With Fire?—One of the most impactful decisions that most of us will make is whether to replace a creaking software system with something new, or whether to iteratively improve the current system. It depends. Laura Nolan explores the technical, organizational, cultural, and psychological factors that matter when we choose between full rewrites or incremental change. video (15m) requires registration