Why do some projects in the field of software development become famous, “live” for a long time, and have positive feedback from users, while others are quickly closed? Most often, the reason for success or failure is the budget. Successful projects exist with well-planned expenses not only for development but also for further maintenance throughout the entire life cycle. The more complex the product, the more money it requires to maintain its competitiveness, introduce even more technologies, and constantly update. And that’s just a fraction of the estimated costs. Yes, sometimes you can give even 90% of the cost of its creation to support software. And if you do not include these costs in the budget, the product will quickly “go to the bottom.” So why is it so expensive to keep software viable, and what should be done to calculate future costs?
Types of software maintenance
Not all customers understand why a product that has been designed and assembled requires additional costs for further support and cannot function without it. Programmers explain the situation using the example of a car. If you buy a car, you perfectly understand that you cannot demand to drive the car without refueling, MOT, or current repairs. With the work of the software, everything is the same and it should be obvious, like the story of buying a car. Indeed, thanks to this, you can get end up with more users than the client and developers originally expected, updating third-party services with which the product interacts, adding new features that customers need, etc.
All software maintenance activities can be divided into 4 groups. Each group requires its investment. Below we present the percentage share of each type in the total cost of maintaining a digital product.
Work carried out after delivery of the product to the end user. For example, after starting work, users complain that one of the application’s functions, related to interaction with a third-party service, does not work. The developer, in the process of fixing it, found an error in the code and fixed it. The work of the bail application has been adjusted. Approximately 20% of the budget costs are spent on such support. But most often, corrective work is needed for new products that are just launched or have a short history of interaction with users.
Any software that interacts with third-party resources needs adaptive work during its entire use. For example, an update occurred in one of these services, as a result of which your product no longer interacts correctly with it. It is necessary to carry out work to resume this part of the functionality. The share of adaptive maintenance in the budget is approximately 25%.
Each supplier of a digital product, if he wants his project to be successful and profitable, is very attentive to feedback from users. For example, after a certain time of use, customers began to complain about interface flaws or lack of features. The developer takes into account the wishes of the customers and adds these features or adapts the interface to the requirements of the customers. This type of maintenance, as well as corrective maintenance, is needed by new applications with a short period of interaction with the end user. The share of such services in the budget is about 5%.
Digital technologies are the fastest changing environment today. If you do not adapt and update the product to new requirements, it will become obsolete very quickly, and users will find a more modern and functional analog. Therefore, software updates should be carried out regularly throughout the life cycle. Such work eats up 25% of the budget for software maintenance.
The percentages in this list are approximate and calculated as averages. Each product is unique, and in one case it interacts more with third-party resources, then you need to budget more for adaptive maintenance. If the application is more autonomous, then it is worth allocating more for updates and enhancements.
What is the cost of software maintenance, and how to save the budget
No specialist can give accurate forecasts for the cost of support. The necessary budget will depend on various factors. Most of the costs will go to technical support:
- The dependence of system modules on each other – the higher it is, the more expensive the maintenance will be, because when working with one module, you will need to work with others;
- The higher the level of a programming language, the easier it is to work with, so high-level languages are cheaper to maintain;
- Each programmer has his style, so fixing developers’ mistakes is sometimes very difficult and expensive;
- Quality of testing – the more tests and checks were carried out at the development stage, the less you will have to spend on maintenance;
- Clear documentation – the clearer and more complete the project documentation is, the easier it is to figure out exactly where the failure might have occurred and how to fix it.
Based on the data, it can be understood that the cost of software maintenance can be effectively reduced through the right approach to technical aspects.
A lot also depends on the age of the software. The older it is, the more it requires implementations and updates. Sometimes it’s easier and cheaper to rewrite a product than to constantly update it.
In addition, the cost varies among the developers themselves and the turnover in the company. So, if specialists are constantly changing in a team, this has a very detrimental effect on the overall result, increasing costs and the time required to complete tasks.
DevOps – assistant in cost reduction
DevOps allows for so-called continuous development. That is, even in the process of modifying certain modules, the system can continue its work. DevOps uses a number of useful scanning and defect detection tools. With their help, you can significantly reduce the time to find and fix errors.
In most cases, it is impossible to build the cost of future maintenance. But it is quite realistic to draw up an estimated budget. Most often it is assumed that it will not exceed 65-75% of the costs that went into development. It is not worth worrying about the lack of exact numbers and worrying that it is impossible to carry out tentative calculations. The main thing to remember is that the better the product was thought out and implemented initially, the easier it will be to maintain it throughout its entire life cycle.