With technology changing so fast, can mobile app code get so out of date that it makes more sense to just throw it away and start over? How long does an app last anyway? Let’s take a deeper look.
DOES MOBILE APP CODE HAVE A SHELF LIFE?
Well, yes. For apps that are written, released to the store and never touched again, a complete code rewrite may be necessary within one to three years. This can be due to changes in the underlying operating system, a new mobile device with a unique screen size or format (like when iPhone X came out with the "notch"), or new security requirements (like GDPR). App changes could also be forced by changes in web services that your app is depending on, by branding changes required by your company or really any number of external factors.
WAIT, IS THAT THE ONLY OPTION?
The good news is, if your application is being actively maintained, a complete code rewrite should never be required. Proper maintenance means that as new features are added, the underlying code is modified to support those new features, and other parts of the code may also need to be rewritten over time in order to support new platform releases. This code maintenance is often referred to as refactoring.
Refactoring is the process of updating app code to make it cleaner, more efficient, more performant or better structured. Refactoring also allows you to modernize your codebase by taking advantage of the latest development techniques and best practices.
Keep a backlog of technical debt, and make sure that each release contains both improvements to the codebase as well as new features. Technical debt is just what it sounds like -- a list of things in your code that you know need to be updated and improved in order to make the code cleaner, more efficient and less buggy. Often, technical debt is the result of consciously taking shortcuts during the development process to avoid obstacles or get to market faster (sort of like procrastination on creating the optimal solution to a problem).
HOW DO I KEEP MY APP MAINTAINED?
The key is to continuously evaluate the codebase to ensure it doesn't stagnate. Any time a new feature is introduced, your development team should assess if refactoring is necessary in the existing code before the feature is implemented. It is also important to adopt the latest changes to external factors that affect your app -- things like platform releases, third-party SDKs and API updates from your web services team.
Sometimes, a platform will make a major change that impacts the entire codebase, but it is still important to take an iterative approach since this helps you build upon your existing code and therefore reduce the risk of introducing issues. When Google released Kotlin (replacing Java as the preferred development language), we took an iterative approach across our organization. First, we rewrote unit tests in the new language to get familiar with it. Next, we started to develop all new features using the new language, which allowed the codebase to evolve while still maintaining interoperability with the existing code. Finally, we actively worked to convert to the new language, file by file, as we touched each area of the app. With this approach, we reduced the risk of introducing issues significantly since we were still using underlying code that was tried and true.
WHEN SHOULD AN APP BE REWRITTEN INSTEAD OF REFACTORED?
Only if the app code has been unmaintained for a considerable amount of time. In this case, it can become more time-consuming to update the stagnant code than start from scratch. My company used to work on games but got out of the business a couple of years ago. One of our games was still being used by some consumers but stopped working with the release of iOS 11 when 64-bit became a requirement. Unfortunately, since we hadn't touched it in years, it would have required a full rewrite in order to get it working. All the dependent libraries had new versions, and iOS had new requirements and features that would have forced a full recompile. Had we been keeping this app up to date as we went along, iOS 11 would have been an easy update, but since we ignored the app for several years, it ultimately ended up not worth the investment to update it.
Refactoring is less risky and more economical than rewriting. Without question, rewriting an entire app from scratch is risky. Invariably, teams end up uncovering new issues in the field. It is much safer to build upon the existing codebase and improve it over time, testing one update at a time, than to completely start from scratch. It is also more cost effective due to the risks associated with complete code rewrites and the implied costs businesses already budget with these experiences. Only in rare circumstances would a complete code rewrite be more economical.
WILL THIS LIMIT INNOVATION?
Not at all. At times, a new feature might take longer to implement if refactoring is required on the underlying code before the new feature can be built on top of it. However, that is a small consideration as compared to rewriting the entire application just to add a single feature.
HOW CAN I LEARN MORE ABOUT REFACTORING?
Refactoring to Patterns by Joshua Kerievsky is a book that is widely used by software developers at my company -- we have several copies in our library. We also have quarterly training sessions on software design patterns and refactoring, which are presented quarterly to the entire development team.
KEY TAKEAWAYS:
- Your app doesn't have a shelf life!
- Refactor code when new features are introduced to the app or the operating system.
- Include code improvements in each release, in addition to planned features and bug fixes.
- Actively maintaining your apps is more economical and less risky than rewriting your app from scratch.
