Keeping the Foundations Strong - Why Refactoring Is Crucial

September 20th, 2016 by inflectra

One of the challenges with development is that users only see the outside of the system, the user interface, perhaps the APIs if they are more technical and unless the system has a problem, the architecture and internals are largely ignored... so how do you get customers to invest in the architecture for the future when they see no immediate benefit.

Why Bother Refactoring?

Well the first question is why bother in the first place? Why not simply just add new functionality (i.e. user stories) based on what the customers are asking for. What could be the problem...

Image: ../Images/top-heavy-house.jpg

In the same way that expanding a house so that it exceeds its foundations is a recipe for disaster, if you don't continue to evolve your architecture, eventually you will not be able to continue to add functionality without the system breaking. For example some of our competitors had products written as ActiveX Windows applications, at some point they needed to become web applications if they were going to compete in the cloud. Similarly with the adoption of mobile devices such as tablets and smartphones, the UI needs to work on mobiles.

How to Pay for Architecture?

Many years ago I was involved in revamping an internal system for a consulting firm and we had this great idea - lets design and build a new architecture upfront, switch from VB6 client/server technologies to a new web based UI and service based architecture. It would take 12 months and cost $x million dollars. Of course the users wouldn't see any benefit until after we added the first features to use the new architecture 16 months later....

Well as you can imagine, this proposal didn't go down to well, firstly because of the price and timeframe and also the feedback that the CTO didn't think we would even get the architecture right without actually building user features to test it.

So fast forward to the Agile Manifesto and the need to have user stories drive the features and have architecture only support what was needed now, how do we make sure we have a foundation that will support current and future needs.

The Refactoring Imperative

What we have found that works well for us is to pay for the architecture a piece at a time, almost like a "tax", for every 100 points of user stories we build, we pay 20 points of an architecture tax. Every release of Spira (for example) we refactor a portion of the system to use a newer technology stack. We also experiment with different ideas to see which will work best.

Image: ../Images/refactoring-architecture-2.png

As the following diagram shows, over the past 10 years we have evolved in this iterative, agile manner from a standard ASP.NET 1.0 application to the rich Ajax, mobile responsive system we have today. At no point in time did we ever have the time to completely rewrite the entire application from scratch, but we have continually refactored it so that it has always been current. This approach takes some discipline, for example it has taken 6 years to completely refactor out the use of ADO.NET DataSets a legacy data-access technology that dates from 2003.

So next time you are asked to plan a sprint or release, make sure you include your architecture tax... you can either pay now or pay in 10 years when your technology stack is obsolete.