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.
Community comments
I am afraid eBay cannot be considered as a reference case here...
by Dmytro Lapshyn,
Re: I am afraid eBay cannot be considered as a reference case here...
by savita pahuja,
Re: I am afraid eBay cannot be considered as a reference case here...
by savita pahuja,
Embrace the change
by Valentin Tudor Mocanu,
I am afraid eBay cannot be considered as a reference case here...
by Dmytro Lapshyn,
Your message is awaiting moderation. Thank you for participating in the discussion.
...and neither can Twitter. These are, rather, happy exceptions from the overall trend to exploit an existing architecture unless it is absolutely unable to support further development. Unfortunately I have seen too many cases when sub-optimal (or even worse - ignorant) architecture decisions remain unchanged for years as project sponsors are totally unwilling to invest into changing something "that works".
In this regard, with all due respect to the author, I would say the closing words about the team deciding when to sacrifice the architecture are pretty far from what actually happens in reality. Namely, it's a very rare occasion when a team owns the project budget and is thus empowered to make such decisions. Perhaps this is the case at eBay and Twitter, but certainly not in the majority of IT companies (even product development houses)
Re: I am afraid eBay cannot be considered as a reference case here...
by savita pahuja,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree the point of not getting finance for changing the architecture. But its the team only which can tell concerned people about the need of change as they work on the code. They know the technological point of view.
The main point here is when there could be need of changing the architecture in future because of fast changing demands and needs of users. Better to be prepared now by writing modular and flexible code.
Re: I am afraid eBay cannot be considered as a reference case here...
by savita pahuja,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree the point of not getting finance for changing the architecture. But its the team only which can tell concerned people about the need of change as they work on the code. They know the technological point of view.
The main point here is when there could be need of changing the architecture in future because of fast changing demands and needs of users. Better to be prepared now by writing modular and flexible code.
Embrace the change
by Valentin Tudor Mocanu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Modularity it is not enough for re-using parts of the solution or of the architecture. The second question is how much from one module could be reused. One answer is the separation of concerns. A Clean Architecture (Uncle Bob) is highly reusable because respect this principle. If for some reasons you are not using a CA (Ex: a framework that mix some concerns), you just need to be productive and economic enough, to have a supplementary reserve of money (... and time) for the supplementary changes.