What are Bugs? Software Maintenance Explained.
All software has “bugs.” But what’s a bug and how do you avoid them? If you encounter bugs, who pays for fixing them?
Everyone expects their software team to design and test thoroughly enough so that the code works as it is expected and performs the set of functions it is supposed to. Software should be tested for every scenario that it is designed to work in. But what’s the expectation if an issue arises that wasn’t envisioned by the stakeholders, designers and developers? In custom software, it’s important to understand what the responsibilities are for a client and a consultant with respect to problems, or bugs.
A very typical issue once the software is complete and deployed is what constitutes a bug – and who is responsible for fixing it.
Generally in custom software agreements, after the software is tested and accepted by the client any bugs that are discovered can be fixed, but at additional cost. An agreement may include a certain number of development hours for diagnosing and fixing bugs after acceptance for some defined period of time. There may be a separate maintenance agreement based on a percentage of the contract for fixing bugs and perhaps compatibility and security issues that may not have been envisioned in the original project’s scope. But it’s important to note that bugs are a part of the risks inherent in custom software projects.
Part of what a client pays for is the expertise and skill of the software development team – a good team will define the project requirements and scope carefully and minimize bugs. Also worth noting is that your custom development consultant may not have control over other projects in your organization or maintenance of existing systems. Sometimes its a change made in another part of the system that breaks the new application. Bottom line – bugs will happen, and not all dependencies are always known.
Let’s look at some examples of what may be considered bugs versus enhancements.
Refers to reactive changes to the software or system to fix problems discovered in normal use. Some examples:
Bugs – things not working as they are supposed to.
Compatibility issues, as in making a site compatible with existing browsers and their different standards support.
Security patches to correct holes.
If the above issues were within the original scope of the project, the consultant will typically fix these within the bounds of the maintenance clause or agreement.
Refers to modifications made to keep the software working properly in a changed or changing environment. Examples of this may include:
Changes to make web site pages work properly with a new HTML standard or a new browser not encompassed in the original project (like Microsoft’s Edge).
Adapting the software to changes in a web service API , like Amazon Web Services, Facebook, or Microsoft Office Graph.
Modifying software to increase functional capacity, as in more simultaneous users, traffic, or data management.
This type of maintenance is usually done at extra cost by the consultant, as it is unlikely to be something that can be estimated or foreseen as part of the original project scope.
Refers to improvements to the software for maintainability and performance. Examples of these include:
More efficient use of memory in an application for a reduced footprint.
Streamlining code for easier readability and maintenance.
Refactoring routines for better performance or throughput.
This type of maintenance can also be done by the consultant at extra cost.
This is just as it sounds: these are changes to correct faults that are either known or expected to be problems at some point in the future.
A great example of this was Y2K. At the turn of the millennium many old software programs were expected to develop errors because of using 2 digits for year date processing instead of 4, as in 98 to denote 1998. Many millions of dollars were expended in making changes to old code bases or redesigning applications to solve this issue.
A more modern example might be to implement two factor authentication for logins to add a security layer for users, or moving from 128-bit encryption to 256-bit to protect against brute force attacks.
Again, this is usually an additional feature to a project unless the scope envisioned making these types of enhancements over a specific time-frame.
Some things that are “maintenance” may require new development.
Maintaining compatibility with a new version of an operating system, browser, or set of web service APIs will involve new coding and testing. Even if the application functionality stays the same, there may be a lot of work involved – at extra cost – to work with the new platform.
Maintenance can mean new opportunities for the platform.
Often the underlying platform change will provide a new opportunity for the application – either subsuming some function that can now be done with an API and taken out of the application, or adding a new service that can add a new dimension or feature to the application.
Streamlining the apps maintenance.
For example, Apple’s newly released IOS10 is opening up Siri voice control for apps other than Apple’s. Essentially that means that now third party apps can expose certain services that can be used by voice. If the app had such a feature before, it can now be performed in a more integrated form in the system, and that functionality is now in the underlying system and no longer has to be maintained or enhanced in the application. Obviously this is not maintenance, but once implemented with a system API it may streamline the app’s maintenance, freeing resource to do other new things.
At eForge, we use our Research, Design, and Planning process (RDP) to scope out a project in great detail.
RDP helps to define what will be delivered and what is potential maintenance down the road. Working with you, we work to define a project to the best level of detail possible, so that we all understand what the deliverables are, what issues may have to be addressed in the future, and what the costs are to achieve all the project’s objectives.