Programmer Musings

Thoughts on Martin Fowler's Sacrificial Architecture

In a recent blog post, I suggested that the most important result of a developer writing code is the understanding of the problem/solution. Most of the reason for suggesting this change in focus is to help people understand that throwing away code that no longer serves a purpose is a good thing, not a loss.

A little later, I ran across an older post from Martin Fowler on Sacrificial Architectures. In this article, Fowler makes the observation that few of our designs last forever. Eventually, changing environments, market conditions, or technology will make any design obsolete at some point. But, he argues that most software has an even shorter lifespan.

He suggests that we plan software so that it can be dismantled or discarded without disruption to the business. We know that this happens, so maybe we should go beyond grudging acceptance of the reality and actually plan to sacrifice an architecture when the time is right. Instead of trying to develop a system that will still be appropriate in 10-20 years time, maybe designing software that will do the current job very well for the next couple of years, knowing that we will probably want to replace it is good.

Current Approach

The current reality is that we often need to do that replacement, but we don't plan for it. So, the only way to replace the outdated system is with a big bang re-write that is so painful that we limp along with an inappropriate design instead. To solve this problem, many programmers try to plan ahead and try to design code that is future-proof. Unfortunately, we are bad at predicting the actual future, so this future-proof code usually doesn't help much. In the meantime, it causes maintenance issues for the current use of the code.

A Different Approach

Instead, maybe we should partition solutions to make it easier to replace whole subsystems as they become outdated. This is really an exercise in the same kind of interface-based modular design we know we should be doing. Fowler says that Google usually designs for ten times the current capacity of a system, but no more. If the system reaches that capacity, it will probably need to be scrapped and re-written anyway. In 2009, a presentation from Google described 7 significant revisions in 10 years.

Very few people will ever have the same kinds of capacity problems as Google or Amazon or Twitter. Designing to handle those kinds of problems up front is wasted effort.

The Web

Since the beginning of the public's awareness of the web, we have seen many repeats of the following scenario.

Company Foo has an idea for a service they think people might like. They put together some proof of concept code and make it available on-line. They may even continue to improve it with a small number of customers. Then, the internet masses discover it and decide they like this idea. Suddenly, they are dealing with more traffic or orders or customers than they thought possible. Now, they scramble madly to get the system updated to support the level of service they now need.

Some services collapse at this point, never to be seen again. Others limp along, improving, but not fast enough, until the customers lose interest and leave.

A few manage to stay just ahead of collapse and people joke about their problems while continuing to use the service. Eventually, they may succeed.

After seeing this happen a few times, some companies/teams decide to build for scale/service before releasing. Quite a few of these spend a lot of time and money, and their idea never catches on, or they never release.

Conclusion

Fowler's suggestion possibly gives a way to be successful (even on a smaller scale) without as much pain. Instead of trying to predict and code for a future that we cannot imagine, try to design for a modest increase over what you currently need. When we inevitably find that customers want something different than we thought, or that more people are interested in our product than we thought, or our whole approach doesn't scale like we thought, we can rewrite and replace the good enough code we start with.

Maybe, just maybe, if we do our jobs right, the original code will keep us going until we figure out and write the next thing we need. Not only has the old code kept things running, it has allowed us the time to learn what we need for the next revision.