Does your management only budget time and money for the development of new software application development and not maintenance? Is management surprised at the ‘cost’ of maintaining applications after they have gone into production? Do they view IT as a ‘money-pit’ because of the increasing costs of maintaining software they thought they paid for in full years ago? Do they understand that maintenance and enhancements of older apps can over time take an increasing percentage of any development team’s time greatly reducing their ability to develop new applications or conversely requiring the IT department to continually add to their staff?
One analogy might be buying a house. As with the initial purchase of a house, the up-front cost of building a new application can be substantial. It is the hope that the software will return a benefit over cost over time typically in the form of improved efficiency, better accuracy, or greater profitability. Initially after going into production, the software may run with little intervention for some time giving people the impression that the project is done. But at some point, someone will request a new feature or a change to an existing feature. In some cases, requests for change come in fast and furious right from the day the program goes into production. In either case, IT management must make a decision whether to address each issue as it comes in or to accumulate changes and then go through a major revision of the application incorporating several of the changes at once.
Of course, getting developers to jump from one application to another to ‘fix’ change requests as they come in can be counterproductive and should be reserved for only critical ‘show-stopping’ issues. The reason is that developers have to build a mental model of the application before they can begin making changes. This takes time. In fact, some studies have shown that even a simple interruption to a programmer to answer the phone or an email while they are working on a problem can result in a loss of 15-30 minutes as they attempt to get back into the ‘zone’. Jumping from program to program is even worse. Therefore, most major development organizations collect changes over a period of time and then dedicate one or more developers to implement all of the changes as a single release or new version. It also minimizes the time needed to test the changes since testing can occur once rather than several times. Moving the application from development to QA and then to production occurs less frequently with the corresponding savings in time and effort. And finally it can make it easier on the end-user so they do not have to change the way they work with the application every couple of days as new features or changes are made one at a time.
If you think about both styles of handling changes to an application (immediate vs. grouped), you can visualize the effect on the overall cost of maintenance not just for one application, but for the entire development team. But let’s say that you have a new application that immediately receives requests for a lot of changes and they need to get in right away. From a project standpoint, you might ask instead why these problems or deficiencies were not found during testing before the product went into production. Was it pushed into production to meet a time schedule rather than held back for all features to be completed and tested properly? Perhaps, the original specifications were incomplete. A common fallacy is that developers should know better about the way the program should work. However, the reality is that developers create applications to a set of specifications. If those specifications are not complete, it is not realistic to expect the developers to necessarily uncover all the deficiencies.
Finally, the last point for now is that any application that is actively used and has had numerous revisions made to the base code eventually reaches a point when making additional changes becomes too difficult. Perhaps the code has become like a plate of spaghetti due to the number of changes. Sometimes the problems are technical as in the case when the original programming language is no longer supported or the database engine is five releases behind the current version and no one really understands how to deal with the limited features of that version. You may even encounter an application written in a language that no one in your organization still knows how to develop code in. The difficulty in trying to untangle the spaghetti or finding a person knowledgeable in that ancient programming language used by the Mayans to create their calendar may lead you to the decision to re-write the application. The advantage of re-writing the application comes from the ability to: eliminate features no longer needed; streamline the code using new functionality and brining all components (languages and databases) up to current standards.
So when is a software project done? Some would argue, never. At least it can never be considered done as long as the problem it is solving still exists. To that extent, management must plan a certain amount of resources (time and money) to manage the changes that inevitably occur. Often this is translated into a percentage of budget or a percentage of staff. Some ways to minimize these ‘after-production’ costs are to insure that the original project (as well as all subsequent updates) are well documented. But that doesn’t always happen. So be prepared for projects with inadequate documentation to consume more time for even the simplest of changes. Also consider that no developer likes to be dedicated to fixing other people’s problems all of the time which I’ve written about before. Good programming standards and best practices can go a long way toward minimizing the time needed for changes and possibly even help reduces problems that need to be fixed. Ultimately, it is the responsibility of IT management to help the appropriate business leaders understand the software cycle in relation to post-production maintenance so as to set realistic expectations. Just remember, like the weather in Florida, change happens.
A last reminder: This Saturday is Orlando Code Camp. This is a free day of training on a large variety of topics ranging from traditional application development, web development, Windows phone application development, and SQL Server development. I will be speaking on the topic: Do You Have the Time? This session is an overview of how to create and use a date/time dimension in SSAS and direct time data usage in relational tables with PowerPivot for Excel (with a little help from my friend, DAX). Hope to see you there.