TL;DR
Maintain your investment in software regularly, instead of putting it off for years (or decades) and then getting upset when you get hacked or a software agency says it would be cheaper to rewrite it than enhance it.
A Brief History of Software Complexity
I’ve been creating software for 23 years now, often as a contractor and mainly in the web and mobile realms. The organizations I’ve worked with range from the smallest startups to fortune 500 companies. I remember the days when C++ and 1200 baud modems were the norm, and dynamic web pages meant Java and JSP pages. JavaScript was for script kiddies who wanted gimmicks and novelties on their sites. Mobile devices and the app store ecosystem that goes with them were just a pipe dream. Git was just a derogatory British slang word I’d never heard of.
Software development was so much simpler then. Or maybe I was less experienced and had less knowledge; probably a little bit of both. As time went on, several things caused the rate of change in the industry to rise what seemed exponentially. Open source software became something not just for those uber-geek, broke, startup people with a dream and a caffeine problem, but widely accepted and used by most of the industry. Computing power in general went up, so more could be done in a given amount of time. Global connectivity and accessibility became a reality. The advent of the cloud made server hardware a commodity service instead of a depreciating asset mess. There are a many, many more factors, but the result is that today software development is a wildly complex, fast changing environment.
Frameworks and SDKs
As the capabilities of software got more complex, developers got tired of recreating the same boilerplate features for every project. Processes such as login and sending email stay pretty similar from project to project. As a result, frameworks were born, grew into their own massive ecosystem, and created a whole new arena for Internet flame wars and “X is better than Y, fight me!” threads. With many of them allowing you to create plugins and extensions, the world of software dependencies has grown ever more complex. As an example, in a given day, I can work with up to seven different languages between two to three clients (if I put one more semi-colon in a Python file after switching contexts, my laptop’s going out the window.) The project I’m wrapping up right now has 31 immediate dependencies. If you include all of the dependencies’ dependencies and so on, 2,559 😵💫. The army of developers needed to recreate all of that from scratch for every project would be immense. We really do stand on the shoulders of giants today.
Maintain Your Investment
Congratulations! You’re the proud owner of a new software product. You’ve just spent a cough bunch of money to have this gem created! You’re done! Yay! Drinks all around! Ehh, no. Well, have the drink if you want one. Just don’t plan on walking away for years at a time. Security and dependency evolution both play roles in the aging of your software. Let’s look at each one.
Security
This one’s kind of a no-brainer. A quick Internet search shows between 250,000 and 500,000 new malware are detected every day as of the time of this writing, and being in the infancy days of AI, you can bet eventually AI will also be writing new malware on behalf of some miscreant somewhere in the world. So that number will likely grow despite what regulations end up being put in place because people are, well, people. Some of those will affect your software on occasion, so for security’s sake alone you shouldn’t ignore your product.
Dependency Evolution
Even if your development project went perfectly, you can’t possibly anticipate every future change to your market, so eventually you’ll want to make changes. Frameworks change over time, and regularly, even without taking into account planned obsolescence, which is a rabbit hole I won’t go down right now. Apple and Android release new OS versions pretty close to annually. Web frameworks and libraries are more sporadic in their release schedule, but it’s a safe bet that changes will happen regularly in a popular framework. Things don’t improve without change (though the “improve” part is sometimes up for debate).
The Crux
There is always contention between product stability and change, whether those changes are caused by security issues, dependency evolution, or product enhancements. I see clients often tempted to just let their software be in the name of stability, and I understand that desire. This usually results in nothing being done until changes are forced on them at some point in the future. At that point, all of the “update debt” incurred to that point must be addressed. This has been particularly painful in the mobile world. An app is released, then ignored for two to three years. Meanwhile iOS and Android continue to evolve. Two to three (one?) years down the road, something breaks in the app on newer phones or the owner wants some enhancements. Now, instead of just adding that feature, we have to spend time updating the existing app to work with the newer OS versions and 3rd party libraries before we can even begin thinking about enhancements. In the case of some apps I’ve worked on in the past that went untouched for 7 to 8 years, my response of “it would be cheaper to rewrite it” was met with incredulity and a vocabulary lesson for me 🤬.
At Zeytech, we’re trying to fight that mindset with an alternative suggestion. Instead of kicking the can down the road or ignoring it altogether, budget a reasonable amount of money each year toward maintaining your software. With a maintenance package, we’ll look at the changes surrounding your software’s ecosystem regularly and inform you of the impacts before they become a problem. This gives you more control over when to maintain and when to let things slide. Security flaws should never slide, but maybe that deprecated feature in Android can wait another year before being addressed. It also leads to fewer surprises when you want to make value-added changes to your software because your dependencies are always up to date and you don’t have to worry about paying all that technical debt in a lump sum just to add a small enhancement. This in turn makes your software more secure, increases your peace of mind, prolongs the value of your investment, and helps you be proactive to changes which your users will appreciate. We’d love to talk with you about how we can help you extend the life of your custom software, and if we’re writing that custom software for you right now, you can trust that we’re thinking about the total cost of ownership for you up front as we develop it to begin with.