In my formative years I assumed that I would have a career in some field that leaned heavily on classical physics. I simply loved the mathematics and how it could capture the motions of the physical world in a few relatively simple formulas. Isaac Newton helped define the idea of inertia in his most famous work Mathematical Principles of Natural Philosophy. Here is an excerpt:
"The vis insita, or innate force of matter, is a power of resisting by which every body, as much as in it lies, endeavours to preserve its present state, whether it be of rest or of moving uniformly forward in a straight line."
So objects travelling (in a straight line) are said to have momentum and in order to change that momentum we have to overcome it's inertia. Given that objects endeavor to "preserve its present state" change is not always easy. So if a big truck (lots of mass) is going really quickly (lots velocity) then it has lots of momentum and inertia is the force necessary to alter its course or trajectory. The greater the momentum the more the difficult the object is to influence.
Software is resistant to change
When you create a software service, or platform the day you release it for public consumption you make a binding contract with developers and customers who have decided that your platform is useful to them. Every part of your software creates a kind of inertia of its own that is resistant change, and poor design is one of the more obvious ways platforms become resistant to innovation.
Just like objects in motion active software can resist innovation, indeed, many decisions you make are weighted by the past. Making changes today is dependent on considerations that existed long before you started thinking about adding new features. I have personally made a career of managing brown field applications that need careful curation and I get to see how we inadvertently create unhealthy inertia when tending to our projects.
There are several ways to measure momentum of your software and we can use that definition to understand the inertia we are matched against when attempting to make meaningful change. If we first take a look at the equation for momentum in physics it is as follows:
MOMENTUM = MASS * VELOCITY
I have used this equation as the starting point for defining software momentum, and we can redefine these variables to complete the analogy:
MASS - The sum of the number of versions of the software you actively support
VELOCITY - The rate at which you are adding features or fixing bugs
The momentum of your legacy app becomes the product of these two variables, and it directly relates to the amount of energy needed to introduce truly innovative transformations. You can immediately see how legacy applications create massive amounts of inertia, because after years of creating supported versions and not necessarily having a plan to sunset the older ones, your psychic weight looks backwards rather than forwards . Maintaining older versions of software enforces existing relationships, and influence the nature of all your departments (development, infrastructure, sales, support) and cement a rigid agreement between your software and the customer.
The more inertia you inadvertently accumulate the more intractable certain problems become, and it is at this point that wildly successful platforms become ripe for disruption. They simply lose the ability to respond to customers in new ways.
Newly developed applications, on the other hand, allow you to immediately alter relations in pursuit of a more profitable or efficient services. Ever noticed how some app or social network comes along and appear to completely disrupt existing services? The low mass of the software allowed them to tackle a problem that larger platforms simply could not adjust to efficiently even with massive amounts of resources and manpower.
How your organization functions is partly defined by the design of your applications and its ability to evolve and adapt. Good design forces your software to remove unnecessary mass, bad design simply adds to its mass, making change a laborious and counterintuitive. Just as important are the ways in which other departments develop around your software inertia, everyone gets to influence inertia not just those writing code.
So my fellow developers, how are you overcoming inertia in your software lifecycle?
Comments are closed.