We have heard a lot about agile processes (for software development). However, is the software you develop itself agile?

Clearly, there is no correlation between the agility of the development process and the developed product. It will be incorrect to assume that if the software is developed using an agile process then it would be agile. Interestingly, the agility of the software matters more than the agility of the development process over the long life of software.

How? Software maintenance costs are as much as 90% of the total cost of software development, when considered over the life of the software. Over its long life, the software undergoes many changes — mostly because the business conditions change. It is important that your software is nimble, and offers ease of change without introducing too many errors.

An article which appeared over a decade ago (reference) explains that this trend is well known since over four decades ago. (Check out the referenced article for an interesting “product lifecycle diagram” that is used to elaborate the point.) Having known this trend for long, it’s a shame that a lot of software being developed today is still brittle. It’s not just that the maintenance costs soar high. There comes a time that the software completely breaks down. The maintenance team throws up its hands and declares that the software cannot be fixed anymore. It’s most tragic when that happens much before the software’s utility expires, as everything comes to a screeching halt.

What can make the software agile and easy to maintain? Here is how it is done today:

• Start with a carefully conceived design (Waterfall) – High cohesion and loose coupling are inherent in good design. They basically mean that we have identified chunks of code which are less dependent on one another.
• Evolve a good design as it gets built (Agile)
• Break the software into several architectural layers (horizontal slicing) or micro-services (vertical slicing)

What works is clear from these approaches. It is the breaking up of the larger software into smaller chunks.

With Xsemble, it is broken down to one more step, to the molecular level as we like to call it. The maintenance is very easy and the agility is very high. It is super easy to reorganize the Xsemble modules, or fix or enhance them, as one module is a small amount of code (typically 5-50 lines). Even if you have a completely new developers, understanding that much code and fixing it would be very easy for them, wouldn’t it? Gartner estimated that 50% of the time goes in understanding the existing code — imagine how much saving we would get when the developer does not need to understand the whole code but just a small module.

Please comment below if this excites you.