Maintenance is a very important component of software development and sometimes overlooked or not even considered at the beginning of a project. A lot of clients we speak to do not know what it is or even understand why they need it. They can sometimes not realise that software development is not a ‘do once and done’ project. Software is meant to be evolved and improved upon, and these incremental improvements may change the look or functionality, but in time will add more value and provide greater ROI.
If you avoid maintenance and leave your project alone for 6 months and then add a feature, do you know what will happen? Your developers will have to do all the required maintenance needed as they find it or they’ll try to leave it alone allowing it to be potentially vulnerable to security issues and missing out on potential code improvements and optimisations. To avoid this issue, we recommend building a proactive maintenance plan around the two types of maintenance that can exist in a software project: Direct and Indirect Maintenance.
All projects have a natural end date which is when the software delivers upon the outcomes defined or budgets run out. Hopefully, the solution that you developed is deployed and begins to add real value to your business and customers. This is when “maintenance” begins.
Maintenance is a continuous process that does not stop unless the software is to be no longer used. Even after the project has been delivered and the outcomes are met there can still be numerous reasons for wanting to make changes or adjustments to the software. It doesn’t matter if it’s an API, mobile app or a website, this holds true.
The following reasons are why most software is updated or changed after it’s perceived “delivery” date:
- New features
- New technologies
- Process Innovation
- Integrations with new platforms
Just because you have delivered your software and it delivers on your initial outcomes doesn’t mean you or your users won’t have new ideas to improve upon it. This can be the most exciting phase of any project where concepts can evolve, new ideas can be introduced from users, new ways of doing things can be raised or new value that you didn’t even know about previously come to a head.
Technology does not stop and rest – it’s a constantly evolving and fast-paced field where things are changed and released every day. Just because your solution has been delivered and is utilising one technology, doesn’t mean that it cannot be improved with new technologies. Integrations can be performed at any time and you could even re-write components, create microservices or sub-components and build them into the software.
So you built your app to automate an existing process, great, it’s now working but it’s not like the 10 commandments – it’s not set in stone. You can make changes and you can innovate the process at any time. You’d be silly not to, especially if the change will introduce new efficiencies or value. Once something is working it’s the best time to dissect it, analyse it and figure out how to improve its value.
Integrations with new platforms
Platforms are like the weather forecast, there’s a new announcement about them every day. You can pick to integrate with any of the millions of platforms that are out there, some might have similar functionality to your app or some might have new functionality that you wanted to develop. You don’t have to scrap your system and jump over to those platforms, you can integrate with them and leverage them to add more without developing everything from scratch. Why would you build-in your own support ticketing system when you can integrate with the zillions that are out there and bring all that value to your own system?
Did you know that there are changes that can occur outside of the above list and are not in our control or even any developer’s control? Software uses various frameworks, packages and platforms. Developers utilise components and packages that already exist to speed up and improve the development process. They do not write everything from scratch as this would cost a lot of time, money and resources to deliver upon. In all of our development projects we use as many off-the-shelf plug-ins, add-ons and frameworks that we can to deliver an outcome as efficiently and effectively as possible. Why would you invest the time to design, engineer, build and test a component when you can buy it or can find an open-source equivalent for a fraction of the price?
A great example of this would be WYSIWYG editor for Angular. Froala Editor is a fully rich editor that any developer can plug-in an Angular web application in a minimal amount of time. By using a plug-in and not building the WYSIWYG yourself you will reduce your development budget by 1000’s of dollars. This is only one example. You will have many plug-ins, add-ons or frameworks in your solution.
While this saves a considerable amount of money when developing it also means is that there is constant maintenance that is required due to any of the following reasons:
- Operating system updates e.g. new version of iOS or Android
- Platform updates
- Package updates
- Security fixes
- Deprecated functionality
Operating system updates
It doesn’t matter if you develop a Desktop App, Mobile App, API or a website – there are “Operating System” level changes that occur that are out of your control.
- On a Desktop, it’s a new version of Windows or macOS.
- On a Website, it’s a new version of Chrome, Firefox, Edge.
- On a Mobile, it’s a new version of Android or iOS.
- On an API it’s a change to server infrastructure code.
All of these changes can introduce new features, standards or prevent old things from working. If you want your solution to remain available and accessible, you need to update your codebase to comply with the changes
When developing a Mobile App you have two choices: Native or Cross-Platform. If you go down the native path then this won’t affect you. However, with the growth of various Cross-Platform frameworks and their ability to run highly performant apps, this applies to more and more solutions nowadays. Now when using React-Native, Native Script or an equivalent, you’re still bound to Operating System updates as well as changes to those platforms themselves. They have their own release schedule outside of keeping up to date with the Operating System updates. What this means is that new versions are released with optimisations, security patches, bug fixes and new features. If you don’t keep up to date with these it becomes a nightmare to make an update to your app when it’s many versions behind.
When developing on any platform there are multiple packages that are used to save time and money and introduce functionality without having to do it from scratch. There are paid packages e.g Telerik and DevExpress and then there are free and open-source ones which are easily downloaded using package managers.
Now, these are all maintained by different developers and they each rely on various other packages as well – I think you can see how the challenge to stay up to date quickly escalates. Just to give you an idea of the scope of this scenario, a brand new React Native project has 1,737 dependencies before you even write a line of code.
It’s quite easy to update the packages – you can do it with one line of code in a terminal, however, any of those could cause a problem with another and then you have a problem. So it’s worth planning out the major updates and understanding what the fixes are to make sure they’re compatible with your codebase.
Security fixes can live in their own segment as when critical flaws are found in most packages, platforms, operating systems, a quick fix is made and released. This provides a quicker response time and aims to minimise the damage that could be caused by any people who have found those flaws. These are normally overlooked by most people but are extremely important. As the saying goes, “A Chain Is Only As Strong As The Weakest Link” – when applied to software, means your system is only as secure as the least secure component. It doesn’t matter how much security you build into your product if there are flaws within a 3rd Party add-on.
This is an interesting point and one that most people don’t even know about. If you’ve built your own custom solution you may have experienced this. It’s the scenario where one day your app is working and then the next day it isn’t. Have you ever received the latest release of your app, all you did was ask for a spelling mistake to be corrected, but then an entire section of the app stops working? You may want to thank Deprecated Functions for this one. Deprecated functions are bits of code that have been selected and chosen to not be used any more; they might make a new function with a new way of doing something or just don’t want anyone using that anymore.
Sometimes you receive a warning in advance and warnings appear when developing, saying that this is deprecated and will be removed, other times it just happens, in the worst cases you don’t even notice and there are no complaints from the code. When these warnings pop-up you have to modify your codebase to ignore them and handle the new way of doing things or come up with the new way on your own.
How to be pro-active
Rather than be reactive and deal with these problems as they arise, you should allow for a maintenance budget to give your developers the time to find, research and plan for and manage 3rd Party updates.
There are many places on the internet where you can subscribe for emails to be notified of the plans for the Platforms, Packages or Operating Systems. You can flag the major packages that you’re using and periodically check for announcements. A few ways you can do this is:
- On Github, you can watch a repository or subscribe to the atom/RSS feed for releases or tags
- Run ‘npm outdated’ to see a list of outdated packages
- Use an external service like https://www.dependencies.io/ to be notified of updates
In doing the above steps you can then forecast and build a plan for the 3rd Party changes that can impact your solution. If you plan for it you can set your app up for continued future success.
It really is important to consider maintenance as MUST in any development process. We’ve seen and heard of numerous stories where people didn’t want to do the maintenance, and then when their next chosen update came around, things have gone south very quickly and a whole can of worms was opened up. Sometimes a simple quick fix can turn into a serious problem with multiple developers and a delivery time frame that was not expected. All because their solution was not maintained.
Being pro-active and on top of Indirect Maintenance is an ongoing investment in maintaining features, functions and security in your applications. It can seem like an unnecessary cost; however, consider the real cost of deploying a feature update and your application failing. Or better yet, your client’s data being hacked as a result of a vulnerable plug-in that wasn’t maintained.
Everything that is built needs upkeep.