Software development teams prefer to have long lived architecture of the softwares but fast changing technological trends in hardware, software and network speeds, demand a major change in the architecture or throw away the entire code base. In the same context Martin Fowler, author and consultant at Thoughtworks introduced Sacrificial Architecture in his recent blog.
Sacrificial Architecture means accepting now that in a few years time team will (hopefully) need to throw away what they are currently building. Martin mentioned that it means thinking now about the things that can make it easier to replace when the time comes but software designers rarely think about how to design their creation to support its replacement.
For many people throwing away a code base is a sign of failure, perhaps understandable given the inherent exploratory nature of software development, but still failure. But often the best code you can write now is code you'll discard in a couple of years time.
Martin gave an example of eBay corresponding to Sacrificial Architecture that how over the period of time they have moved from perl scripts to c++ code to java code. The right architecture to support 1996-ebay is not going to be the right architecture for 2006-ebay. The 1996 one won't handle 2006's load but the 2006 version is too complex to build, maintain, and evolve for the needs of 1996.
Dmitry Cheryasov, developer at EPAM Systems also supports Sacrificial Architecture because of the changing business needs. He shared his views in a discussion at Y Combinator as:
Build with an intention to rebuild when the time comes. It's like throw-away prototypes, only in production. When your business grows, you may have to throw away some or all of your previous code base (as eBay did, twice). This does not mean that the previous solutions were bad: not at all, they were adequate for the previous step.
Jeff Dean, senior fellow at Google mentioned in his presentation to redesign or throw away the code before it gets too old.
Right design at X may be very wrong at 10X or 100X..design for ~10X growth, but plan to rewrite before ~100X
Martin says that in the early period of software system there is less surety of what software really needs to do, so it is important to put more focus on flexibility for changing features rather than performance or availability. Jeff Atwood, co-founder of Stack Overflow and the Stack Exchange Network, coined the phrase "performance is a feature".Therefore team can prioritize the performance feature with respect to other features. Initially it is not of higher priority but at the later stage of development its priority gets increased.
Martin says that Sacrificial Architecture doesn’t lead to lack of quality. For a healthy code base, modularity is the key.
Good modularity is a vital part of a healthy code base, and modularity is usually a big help when replacing a system. Indeed one of the best things to do with an early version of a system is to explore what the best modular structure should be so that you can build on that knowledge for the replacement. While it can be reasonable to sacrifice an entire system in its early days, as a system grows it's more effective to sacrifice individual modules - which you can only do if you have good module boundaries.
Justin Meyer, jQuery consultant and co-author of JavaScriptMVC, CanJS, and jQueryPP, shared the importance of modularity in his recent blog as:
Modularity is the most important characteristic of a maintainable app. A modular app is not wasteful - parts can be changed, replaced, or thrown away without affecting the rest of the app.
Martin says that the team that writes the Sacrificial Architecture is the team that decides its time to sacrifice and it is good to know about the code that is going to be sacrificed in the future.