PracticeChange

ThoughtStorms Wiki

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.

https://www.artima.com/articles/collective-ownership-of-code-and-text

In particular, a lot of the rational for BigUpFrontDesign is that it's allegedly easier to fix problems earlier than later.

And people are frightened to make changes later, because it seems to require a lot of work. (You have to read and understand the code you wrote earlier, when ideally you'd like to forget about it.)

Instead he recommends that you deliberately practice making changes - possibly even deliberately making mistakes or simplifications you know will have to be fixed later, in order to face what frightens you.

Practice and get good at making changes. Then making changes later in the project won't be so bad