What to consider after going live, planning and design
Photo by Tekton on Unsplash
After months of hard work, green-lighting quality metrics, passing FATs and SATs, your software is now ready for prod. You flick the switch and you?re live. Congratulations.
Users begin to use your software and the first bug reports start hitting your issue tracker. As your features get exploited more and more, new ideas and enhancements reach your feedback channels. A security report comes in, tagging a well-trusted library with a serious vulnerability. Your software needs maintenance, but have you properly planned for it?
Types of software maintenance
As engineers we love to build things, but will our creations stand the test of time? Have you imagined a public road without its asphalt ever reapplied? A car without ever going to a service-garage? How about a metallic bridge that is never recoated for corrosion? Although software may not manifest in the form of a physical object, it surely undergoes decay and needs to be maintained to remain operational:
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes. ? Wikipedia
The study of software evolution and maintenance has always been a hot topic in software engineering, with research stemming back to the early 70s reaching up to the present day. The latest standardisation effort for software maintenance is present on 14764?2006 ? ISO/IEC/IEEE International Standard for Software Engineering ? Software Life Cycle Processes ? Maintenance. In its 44 pages, ISO/IEC 14764 defines four main categories for software maintenance which I?m going to, briefly, explain next.
Identifying the type of maintenance required to handle a modification request (image by author)
Corrective maintenance
This is, probably, the easiest type of maintenance to identify. A user complains about a feature of your software not working as expected. Your testing team tries to reproduce it and, alas, the user was right: we have a software bug.
The role of corrective maintenance is to perform changes to the system to align it with its original requirements and specifications. It?s almost always an intrinsic part of the contract you?ve signed with your client, either in the form of an explicit warranty or as an additional time-bound service.
Preventive maintenance
After your rollout to prod, users are happy with the functionality and adoption widens day by day. The functionality of your system is utilised in any imaginable way, and sometimes? in unimaginable ways too. Those edge cases, make you wonder how the code will behave in circumstances you have never tested during development. You roll up your local dev-instance to check them out, just to realise that a specific combination of user actions, one nobody has ever thought of performing before, may lead to an error. It?s time to correct this potential error before it even has the chance to manifest to your users.
This is where preventive maintenance comes into play. As its name implies, it is the type of maintenance you perform in order to prevent something from happening. If your testing team has found a combination of actions that might not result in the expected behaviour, don?t you want to patch this potential problem before users are affected by it in production? It?s time for preventive maintenance.
Adaptive maintenance
Your system managing the business processes of department X becomes increasingly successful. Other departments start to notice. They quickly realise potential synergies and ask for its API documentation. You, naturally, point them to your online OpenAPI page. A few weeks later they come back telling you that they?d love to integrate with your system but they need some additional endpoints in your API. You roll up your sleeves and prepare for a new release, all part of your adaptive maintenance services.
Adaptive maintenance entails all changes to the system that were not part of its original requirements and specifications. Adaptive changes may come out of necessity, for example, a forthcoming upgrade to the underlying operating system that might affect your system, or by users asking to implement new requirements.
Perfective maintenance
Your system has now become part of the daily routine of all users and data starts to accumulate. But as more data is stored in your data persistence layer, certain areas start to become slower to operate. A page that used to open in under 1 sec, now takes 5 sec to open. The system is still operational but users start complaining about its performance. Time to revamp that 5-levels deep SQL-join that used to work fine when you only had 10 rows in your tables.
Fixing issuing pertaining to the performance of your system is a frequent manifestation of perfective maintenance. But perfective maintenance can also contribute to future maintainability, for example, by creating or enhancing documentation of sub-systems, external systems, and components.
Designing for software maintenance
The design of your system has an integral role in its future maintenance. Specifying the architecture, setting development goals and standards to be followed, as well as choices for the final production deployment may all contribute positively or negatively to future maintainability. As a seasoned software architect, it?s your duty to think of maintainability as part of the original requirements of the system.
There is a lot you could do, design, and prepare for, to ensure smooth maintenance once the system goes live:
Positive maintenance contribution vs cost (image by author)
As you can see in the above figure, there?s a rich mixture of different things contributing to the maintainability of your system. When designing for software maintenance, perform a pragmatic evaluation of the current situation in your people, skills, infrastructure, and culture. Identify what needs to be fixed, changed, or enhanced to deliver software that not only you?re proud of at the time of delivery but also in the years to come while maintaining it.
Planning for software maintenance
Don?t let your planning for software maintenance take place late during the execution of your project. Planning for software maintenance requires not only thinking about the activities that should take place during the maintenance period but also making sure that all people and the required resources will be available when requested.
Document your plan in a Software Maintenance Plan document and have your client read it and understand it. For example, if your capacity for delivering perfective maintenance after the delivery of the project is 2 FTEs for 12 months, make sure that this is commonly agreed between you and your client. If your call-centre operates only during work-hours, let your client know what alternative mechanisms will be put in place in order for requests to be submitted at any time.
A hot topic when discussing software maintenance is about the effort involved. How much, in terms of effort/person-days/budget, should you plan for the maintenance of the software you just delivered? Should you reserve most of the effort to correct bugs (corrective maintenance), or to implement adaptations (adaptive maintenance) in a quick-changing environment?
A common misconception is that most of the maintenance effort should be reserved for fixing bugs. Of course, any piece of software will have errors and will eventually need corrections. We?d be defying decades of software engineering experience denying that. However, if you have followed a thorough development process, the vast majority of bugs should have been caught before the final delivery.
In practice, there have been several studies showing corrective maintenance to amount at approximately 20%. That coincides with my personal experience too. That leaves another 80% for your other three maintenance activities:
Effort distribution of software maintenance (image by author)
The above distribution will, naturally, vary according to the exact circumstances, culture, and business domain of your project, however, it can serve as a good starting point when planning. If you work in a larger company where multiple software projects are designed, implemented, and delivered, gathering maintenance statistics from your projects will be an invaluable tool establishing a company-specific baseline.
Conclusion
Thinking and planning for maintaining your software product should be an intrinsic part of your overall project delivery methodology. Try to think about maintenance as early as possible and document thoroughly what types of maintenance you are able to deliver. Make sure your client knows and understands his/her options as well as any associated restrictions.
Even if your resources are limited do not skip planning for any of the four fundamental maintenance types. Corrective, adaptive, preventive, and perfective maintenance will inevitably be needed for any project you want to see being successful in the long run.
Thank you for reading this piece. I hope to see you in the next one.
