When talking about an application or an information system in general, the maintenance phase is usually skipped over or it is not well planned for. Nonetheless, this is the phase that will take most of the time because it will last as long as the system is relevant. Sometimes, even when the system is no longer relevant, it needs to be supported while a replacement is being built. Here, I would like to cover some factors that we need to account for, so we have a plan for system maintainability.
The different factors that influence a system’s maintainability are latent defects, the number of customers, the documentation, the personnel, the tools, and the design or architecture of the applications.
Latent defects are a list of undiscovered errors that are embedded in the system (Valacich & George, 2021). Perfection does not exist in human-made applications. Thus, there will be defects even if the application is well-planned and follows all the quality standards. Every time that we change the software, there are chances of adding bugs that become undiscovered until they create problems for the users. According to Kan (2003), 95% of the defects are found up to four years after the software has been released to the public. So, errors and bugs are expected even when your application passes all the current tests.
The number of customers is the users of the application (Valacich & George, 2021). They influence the maintainability of the application because their needs are based on market changes. Also, different stakeholders would want different features that are according to their goals. All of these customers will make new requirements that will change the application’s functionality in the future.
The documentation is about the existence and quality of the documents and comments in the code which makes it easier to jump into the right file and make the necessary changes (Valacich & George, 2021). Poorly documented software takes longer to maintain because developers need to relearn what the code is doing each time they need to make changes. Comments within the code help developers to understand what is happening so they can jump into making changes immediately. These comments are useful when there are clever approaches that are not self-explanatory. I personally prefer four lines of clean and understandable code over one cleaver and obscure solution. We sometimes put too much emphasis on speed and performance (saving 1ms) which might not be very relevant in real-world applications.
The personnel is the team of developers and designers that are in charge of making changes to the application (Valacich & George, 2021). The quality of the application depends on their skills and experience, so they don’t introduce new bugs or usability issues. Even if the team is composed of only senior developers, everyone in the team has different levels of skills. One developer might be more versed in the programming language used while another might have more skills in the database management system.
The tools are all the applications that enhance the developer experience and reduce the hours dedicated to maintenance. For instance, a good IDE can generate boilerplate code that can be easily modified and adapted to the requirements of the application. Now with AI, we might see a shift to fewer developers and more tools used to create applications. Developers could become supervisor of what machine generates in the future instead of coding applications from scratch. Developing websites and applications from scratch was a very common practice years ago. However, it is cumbersome to start from zero considering that AI can do a lot of the heavy lifting for you.
Well-structured programs are about the design or architecture of the application. This means how well the application was planned for future changes. This is also related to tools because if the right tool for the job including programming languages, libraries, and frameworks are used, fewer changes will be required to the architecture or design of the application.
In brief, maintenance is as important as the development phase. This is the longest phase in the life of a software project and we need to consider all the factors that might influence changes to the system. These factors might force large rewrites of the application if we don’t plan accordingly.
Kan, S. H. (2003). Metrics and Models in Software Quality Engineering. Addison-Wesley.
Valacich, J. S., & George, J. F. (2021). Modern Systems Analysis And Design (9th ed.). Pearson Education Limited.