An estimate, in software maintenance, is a team’s best guess at the amount of time and effort they will need to resolve an issue or create a new feature.
Business owners have good reasons to be suspicious of estimates. Most companies don’t have an endless supply of time or money. It can be unsettling to hear things like: “it depends” and “it could be a range from…” In most cases, your maintenance team is not trying to rip you off. Instead, they’re usually working hard to set your expectations.
Factors that influence estimates
As a business owner or decision maker, it’s important to know what your maintenance team is dealing with when you ask for an estimate.
Software development is complex work. There are dozens of different things a maintenance team has to consider before they can fix a problem or change the way your system works.
Some of the most common factors that influence an estimate in software maintenance include the:
- age and size of your codebase – including the amount of unused code that has built up over time;
- complexity of existing software development patterns (or the lack of any obvious ones);
- presence and completeness of documentation within the code (comments) as well as alongside it (documentation);
- number of Application Programming Interface (API) connections to outside systems; and
- testing and Quality Assurance (QA) approach your original software developer(s) decided to take.
In the early days of working with a new team, it’s important to understand that context has the most significant influence on your software maintenance estimate.
The context for software maintenance estimates
Most modern software is highly configured to meet your specific business needs.
This is true for both custom software applications as well as systems you might not usually expect. Cross-platform development tools allow developers to build multiple web and mobile application versions from a single codebase. Even eCommerce websites and some Content Management System (CMS) websites can include complex integrations with other systems and tools.
Estimates help everyone stay in step with each other.
Code Reviews
Before your maintenance team takes over the project from the person or team that built it, they’ll probably conduct some type of code review or other assessment.
The code review process lets a team take a look around and see the general condition of your codebase.
The team will look at your overall architecture, your source code repository, your hosting environment, and your deployment processes. Most free reviews take a few hours – at most. An evaluation you pay for might take a bit longer and be more detailed. Whether you pay for the review or the team does it as part of a sales process, that team will only be able to look at a small part of your overall system.
Why teams create estimates
In the earliest days of a maintenance project, your new team will know comparatively little about the complexities of your system. How could they know more than, or even the same amount as, the people who built it in the first place?
Over time, your team will gain experience with the codebase. As they do, the accuracy of their estimated time and effort required to make changes will improve. In general, a more senior maintenance team will make faster progress – assuming your system is in reasonable condition when they take it over.
An estimate is an investment you make in your new maintenance team’s understanding of the systems you’ve asked them to support.
If you’re prioritizing low cost resources, you should expect estimate accuracy to remain low for an extended period of time – even in a moderately healthy codebase.
How you should expect estimates to work
When you report a problem or ask for a feature enhancement, you should expect the team to provide you with an estimate. In some cases, the team will be able to provide an estimated level of effort without any further investigation. More often, though, the team will need some time to investigate. This means there are really two different kinds of estimates:
- Investigation Estimates
- Solution Estimates
In both cases, estimates work the same way.
Investigation Estimates
Sometimes called a “planning” estimate, an investigation estimate is typically small. The team will usually need between 1-3 hours to reproduce the issue or plan out an initial feature design.
The primary purpose of an investigation estimate is to provide the business owner with information that will help determine whether or not to take an action.
In some rare cases, a solution is obvious and the team is able to implement a solution. In most cases, the effort to correct an issue or implement something new will be larger than the investigation or planning estimate.
Solution Estimates
Once a team has explored a root cause, they can provide you with a more accurate implementation estimate.
This estimate is still an educated guess.
Estimates, Decisions, and Guarantees
An estimate is not a guarantee. It’s a tool for you to learn more before you make a decision about how to move forward.
You should always be prepared for an estimate to change based on what the team actually learns during the work. Neither you nor the maintenance team can know real cost in time and effort in advance. It’s the nature of working in a complex environment.
You should, however, always expect that your team is working with both 1) transparency and 2) your best interests in mind.
Maintenance teams should be proactive and reach out as early as they know that an estimate is going to be too low. They should be able to provide a recommendation on next steps and how much more time they think they will need. You should expect to make reasonable tradeoff decisions based on what they bring to your attention.
What shouldn't happen with software maintenance estimates
There are really only two things that shouldn’t happen with software maintenance estimates:
- Unpleasant surprises
- Unfair treatment
Unpleasant Surprises
Nobody knows everything. Even though the process of making estimates is an ever-changing exercise, good collaboration means surprises should be kept to a minimum.
Unfair Treatment
It’s important that business owners and decision-makers understand the complexities of software development. Your solution is as unique as your business model, your investment level, and the people who built the system in the first place. The more collaborative you can be with your maintenance team, the more comfortable they’ll feel in bringing you critical information instead of trying to force solutions into educated guesses when things change outside of their control.