sacrificial-architecture

Like what startups do to test viability... doesn't need to scale, and may be rewritten later.

podcast-rr-178-refactoring-with-martin-fowler#sacrificial-architecture

"And actually, the post I was working on this morning which hopefully will be out by the time this episode goes live, is on what I'm referring to as sacrificial architecture, the idea that sometimes it's perfectly okay to say, "I'm going to build this system," particularly in context of things like startups but I suspect in many other contexts as well, "and I'm not going to worry about what happens if it gets 100,000 users, because I'm going to build it with the expectation that once it gets up to 10,000 users, I'll throw it away and rewrite it from scratch." And we don't tend to think of software deliberately written to be thrown away once you get beyond a certain size.

But often, it actually makes sense because to build a system and try to put too much scale ability to it early on, that imposes a lot of extra baggage that is going to be a problem if you're still trying to figure what on earth the system ought to be in the first place. And you look at a lot of successful website outfits, they did this scratch, rewrite, throwaway business multiple times. EBay is an example. Twitter's an example. Amazon's an example. It's regular practice at Google. But what we're not yet ready enough, not yet got enough, is that sense of when do I make that cut between rewrite and refactor. And unfortunately, it's like so many of these things, it's experience and it's not something that I can find easy to describe at this point."

 

Referring Pages

spike-then-stabilize-vs-tdd