Decommissioning a mobile app is not an admission of defeat. Good software architects know that there is no failure in the world of information technology, only feedback. “The learning loop isn’t just for development." says Mik Kersten, CEO of TaskTop. "It needs to happen from requirement right down to reviews in the app store.” In fact, you can take that even one step further and say the feedback loop should include the entire mobile ALM process, right through to the decommissioning of the application as well.
Five ways to learn from the mobile ALM process
So how can an organization learn from the deployment of past mobile applications so as to help them improve the quality of the software they will release in the future? Here are five smart tips to guide you through the process:
- Identify the best pieces of code and most-loved functions from your legacy apps for reuse or integration into new apps
- Understand user requirements better for the next app by opening the floor to final discussions about the app (give it a "farewell party")
- After decommissioning, gather feedback on how the process of app removal affected users (make sure you didn’t accidentally break something else)
- Determine whether a different balance of native/HTML5 code would make decommissioning easier on apps you design in the future
- Find ways to streamline decommissioning so that you have a formalized set of procedures and it is truly seen as part of the normal mobile ALM
Rising to the mobile ALM challenge
The short software development lifecycles that exist in the mobile world make keeping up a challenge, but they also create an opportunity for software to be iteratively and incrementally improved at a faster pace than ever before. All applications must be decommissions at some point, but good software developers know that the end of an application's lifecycle is a great opportunity to reflect on lessons learned and subsequently channel that learning into future software releases.