When we talk about open-source software development, we think the software’s installation/deployment is the final stage. The understanding is that the software after deployment or installation would run on its own and does not need human intervention. It can be deployed in multiple settings or scaled up, and it will keep running as it is doing right now. But that is far from the truth as the software now goes into MAINTENANCE mode and thus begins the software development life cycle (SDLC) management. As we all know that a car needs regular maintenance to keep it working for longer by ensuring that all the parts are functioning properly and not creating stress on your car's engine, software too needs similar upkeep.
Software development is never complete and there is always some work required till it is being used. Fixing bugs is just a small subset of software maintenance. The software also needs to be regularly updated to meet new system requirements and data regulations. There are also recurrent requirements to integrate new features, and make it compatible with any new hardware and software environments. SDLC includes four types of maintenance: corrective, adaptive, perfective, and preventive. Inspired by perspectives that others have shared, we will try to briefly elucidate these four types and help explain what goes on “Behind the Scenes” when maintaining a software product.
Why is software maintenance required?
Software maintenance is critical to ensure optimal performance, compliance, reliability and security of the system and demands adequate investment. Client/ customer needs evolve with time and the software needs to keep pace with it. Consistent investment in software maintenance ensures that users can derive a high value from the system already designed for them and also avoid developing any new systems which will usually add up to be more expensive.
Software products are not run in isolation and are usually a part of an ecosystem that can evolve and change, forcing clients to adapt the software to circumstances and external factors. Some of these changes are:
Regulatory Change: a software product needs to be adapted to comply with latest laws and regulations. For example, when data privacy laws change, some changes might need to be made on how data is stored and retrieved
Security Changes: security vulnerabilities, cross-site scripting, firewall issues etc could be discovered at any stage and product needs to be upgraded to newer versions to keep the software secure. Constant security monitoring is required for any product.
Environment Change: for example, operating systems, authentication protocols, cloud storage requirements etc change, the application needs to be updated accordingly.
Usage Change: Increase in traffic would necessitate infrastructure scale up changes and need rigorous stress testing to ensure software uptime is not compromised
Categories of Software Maintenance:
All maintenance related to fixing the bugs and any small flaws in the system can be categorized as corrective. Users report issues from the ground which need to be addressed fairly quickly. For example, communication breakage between telecom service providers and our API may lead to SMS interruptions. At times, small updates are required in the code-base to improve user experience, performance and reliability. One also needs to ensure that making a change in one feature/ requirement does not adversely affect any other workflow. As the nature and frequency of bug reporting is usually unknown, right team size needs to be allocated for this work to be able to address issues according to defined SLAs.
Software is operated with predetermined infrastructure requirements. However, these evolve over time and necessary amendments need to be made in response to environmental changes like new hardware, or operating systems. For example, during some deployments, we observed that old tablets could not support the system due to outdated OS. In such cases, engineers need to investigate if the issue can be resolved and adapt the system if possible. Tech environment today is changing at a very fast pace and it has become very important to be agile and adapt to new changes to keep everything up-to-date and secure. This is highly essential but low visibility maintenance work.
A large share of maintenance work can be categorized under this bucket. This includes enhanced usability and functionality of the product. For example as the usage evolved, we reworked on our database structure to improve search capability and reduce load time. This would also enhance reporting capabilities and improve user experience. For low resource settings with limited internet bandwidth, this became a crucial task. During the entire lifecycle, various such enhancements lead to better performance, improved user interface and usability. These types of changes are necessary for better and consistent adoption of the software by the users.
This maintenance makes the software ‘future proof’, preparing it for any likely future changes thus increasing the shelf life of the software. This may include updating documentation, managing legacy data and code, and identifying latent defects in the product and correcting it before they surface in regular operations. A lot of QA and testing is continuously undertaken to identify future potential problems and correct them proactively.
Software Maintenance Cost
Most of the software costs are perceived to be associated with building the software. One usually thinks that if we have already paid to build the software and don’t require any more features, why should we invest even more to maintain it? Research studies show that on average the maintenance phase makes up over 50% of the total cost of the entire project. A research paper called “Distribution of Cost over the Application Lifecycle – a Multi-case Study” finds that for a total production time of 5 years, the percentage of non-recurring costs (initial development cost)) amounts on average to 21% of the total life cycle costs. Therefore, 79% of the total costs are recurring costs, i.e. are further development and production costs which includes maintenance.
Should I do it myself then?
A software product is built with lots of months or years of planning. It usually comprises millions of lines of code which interweave multiple modules and use cases. When one makes changes to one place in a software system, it can have unintended and unforeseen consequences in other areas. This is especially true for multi use case systems where various workflows are interconnected. Hence, it is best that the developer takes the role of maintenance as well. This reduces the risk of negative consequences and ensures that the changes are made with prior knowledge on how the system is structured.
Software maintenance is hardly an option; it is a definite requirement. As discussed earlier, a poorly maintained car will be a problem later, same holds true for a software. Also, the total cost of ownership for an poorly maintained car will be much higher than the one with regular inspection or maintenance. Hence, it is an investment to increase the shelf life of what is already created.