Entropy is inevitable. It’s everywhere we look, within everything we do. All things gradually decline into disorder. However, this does not mean we cannot fight back. But first of all, we need to make sure that we are not making things worse by accelerating the degradation process. “Starting light” is the best strategy to control software entropy from day one.
You have an idea for a software product that can have an impact. You collect a team of similarly minded, technically focused people, and you start designing it. You select a programming language, a modern framework and other cutting edge infrastructure to make it happen.
After 4-5 months of developing you are ready to launch. “Giving birth” is full of excitement but it is only the beginning of a long journey.
Assuming your initial hunch was correct, people start buying your product. And they start bombarding you with suggested new features. You personally also have a list of things that you would like to add to the product. And so, in iterations, you start making your software a better fit for your customers.
There is no end to this journey. The market dynamics guide you to an endless loop of product iterations. With each one, your product becomes a bit bigger and a bit harder to manage. This is the trap of software entropy.
You see, with each new feature you add technical debt. The term is mostly used to refer to “shortcuts” when you select the fastest instead of the best solution to a technical problem.
However, more broadly, each new functionality is a technical debt by itself: you need to ensure that every additional feature works with all previous functionality and that every modification in the UI does not break customer customizations. This means additional work and testing with each iteration.
At some point, you have accumulated enough technical debt that you start thinking of redesigning part or maybe all of your product from scratch. As new members join the tech team, they also bring suggestions about a more modern way to do things or a marvelous library that can produce improved results. Junior (but upcoming) programmers often believe in a marvelous framework or library that will save us from all our problems.
But you know that rarely is a new technology alone the solution to an old problem. At the same time, your problem persists: you cannot efficiently grow the product any longer.
But it makes a huge difference how fast you will get there and how you’re going to treat the problem. I have observed numerous times young and energetic teams starting on a new software project with an enormous technical debt from day one. They opt in favor of an exotic technology, organized in multiple complexity layers, which they haven’t completely mastered.
This may give the team some steam to start with or a social “badge” that they work on cutting edge technologies. But those are vanity metrics. The hard truth is that the lighter you start the further you go.
Starting light comes with tremendous advantages. Rarely in life are decisions final; software entropy is no exception. Actually, in software projects it is worse: directions change often, technologies and providers come and go daily, startups pivot and then pivot again. Having a light infrastructure is a lot of help in such situations as you may turn the ship around faster and easier.
Starting light can be translated to a few practical suggestions that control the software entropy you will invariably face:
Start with the minimum of technologies
Ask yourself a simple question: In the future, if you need to replace technology A with technology B or provider A with provider B, will it be easy? Although impossible to change everything, try to not lock yourself into a single provider or a black-box technology.
Refactor often
Consider code-optimization and rewriting as an integral part of each release and not the last thing on the last day before the release. It might cause a change in the way you plan your project, but the benefits of streamlining your code and reducing the rate of software entropy are well worth it.
Crosscheck software commits
Have teams of two working on the same software commits. Two pairs of eyes as crosschecking on commits can considerably reduce your technical debt.
New features work hard to get made
Use the rule of 3: consider a new feature for implementation only after three different customers request it or, if it is your own idea, after 3 different points in time you “catch” yourself considering it. Making sure a feature is a sine qua non will ensure that the cost software entropy is offset by the benefits you’re adding.
Of course, the above suggestions cannot eliminate the software entropy which is inherent in your system. Most of the times they don’t even reduce it; they rather reduce entropy’s rate of increase. Still, in the long run, their compound effect can make or break your project and be the deciding factor between financial viability or a colossal failure. Take them with a lot of salt, shape them to fit your purpose but decide to ignore them at your peril.
About the author: Athanasios Papagelis is the co-founder and CTO of Epignosis, holds a Ph.D. in Computer Science and is an avid lover of software development and implementation.
Leave a Reply