Delete or develop – An architectural dilemma
The eminent Martin Fowler recently wrote about the importance of not being afraid to bin old solutions and implement brand new architecture. Should IT architects leave old solutions or start fresh?
It’s a well known fact – the older the building, the higher the maintenance bills.
Eventually, most of us realise that it’s cheaper and easier to knock down the building and create something new. This principle is not only relevant to buildings but it is also a useful reminder for IT architects.
Martin Fowler (something of an expert on the subject) recently noted in a blog post that even the most talented IT architects reach a point where they have to admit that the best code sometimes belongs in the bin. At this year’s JAX London, Greg Young made a similar point in his keynote on “The Art of Destroying Software”.
“My favourite kinds of commits are negative ones – ‘I just deleted 4,000 lines of code’!”
eBay is a prime example of a company that adheres to this policy. eBay has completely demolished and rebuilt it’s architecture several times over the years. Fowler notes that the versions were not destroyed because they were bad, they simply did not match the company’s growth and no longer met the requirements.
Any architecture created in the 90s would be overburdened with eBay’s current requirements, while conversely the architecture of the 00s would have been too complex and maintenance heavy for contemporary needs.
The problem of scalability
Google has incorporated the issue of scalability into its corporate philosophy. A system must be capable of ten times the limit that it was originally designed to meet. If this limit is reached, the company begins again at zero.
Fowler mocks newcomers involved in a project with older code because of their lack of performance or scalability. Newcomers often overlook the important role that flexibility plays in an initial phase of a system, especially when you’re not sure what the project needs to achieve. Performance is still important too, but Fowler believes it should be one feature of many. If the focus on performance is too strong other areas will become neglected.
The solution to the dilemma that burdens many IT architects goes by the name of “Sacrificial architecture”, as Fowler explains. But what is meant by an architecture that is sacrificed willingly and intentionally?
From the outset, people should accept that the architecture created in the development phase will be completely discarded within a few years. If people think about the end product during the design process, this will ease the transition to new versions.
Designing the basic code after the block principle is the best approach according to Fowler. It’s much easier to replace individual modules instead of a whole system. Modularisation also provides new features within existing systems. You can provide a small group of users with access and through feedback you can decipher if the system works in this form at all. This is also cheaper and less time consuming at the end of the day, then having to discard a completely finished feature.
Although modular interchangeability is a basic component of micro services architecture, Fowler does not recommend applying this principle in relation to sacrificial architecture because distribution and asynchronicity of micro services increase the complexity of a system considerably. Instead, Fowler suggests a monolithic architecture as the basis of the sacrificial architecture, with the option to add micro services at a later date.
But in the end, the important thing to remember is that deleting code is just as commendable as writing it.