10 Laws of Software Estimating
Why are software projects so difficult to estimate? Having spent over 250 combined years in the business of software estimating, the FLOvate team has devised the ‘10 Laws of Software Estimating’. In this article, we explain why accurate software estimating is so difficult – and how the LEAP low-code platform can help you overcome the challenge.
Why is software delivery so hard to estimate?
In our daily lives, it’s natural to ask “how much is this going to cost?” before committing our hard-earned cash. From getting the car fixed to home improvements; we look for that fixed quote before agreeing to the work.
So, why is it seemingly so difficult to get an accurate estimate for a software project? For a start, we can estimate small software projects to a high degree of accuracy. Certainly, many software-related tasks are simple to those completing them. On many occasions, the same people will complete the same, or similar tasks, many times, becoming increasingly familiar and efficient.
Custom software projects are a different story. Projects that require ‘tailoring’ to business need are often much larger than comparative tasks. In fact, when compared to non-software projects of the same size and complexity, they are commonly subject to the same kind of time and cost overruns.
Moreover, even the word ‘estimate’ is open to misinterpretation.
Roughly calculate or judge the value, number, quantity, or extent of.
An approximate calculation or judgement of the value, number, quantity, or extent of something.
It seems clear that estimates are, by their very nature, inaccurate.
Low-code software can help
To understand this problem, let’s borrow from Donald Rumsfeld. His famous phrase “There are known knowns” is apt. By turning as many unknowns into knowns, we can reduce time, cost and risk in software implementations.
Low-code platforms, like LEAP Low-code, powered by FLOvate, have made a giant leap (excuse the pun!) towards removing unknown unknowns in software projects. By providing software as a set of low-code components, you have a much better handle on how much effort/time/cost a project will take to build.
You can learn more about LEAP Low-code and our estimating best practices throughout this article.
For now, let’s turn to The 10 Laws of Software Estimating.
In our view, estimates are:
- A Waste (or are they?)
- Often Competitive
- Based on Experience
- Only as good as the Requirements Statement
- Carry Material Interpretation Risk
- Only include Productive Hours
1st Law of Software Estimating: Estimates are Necessary
It’s important to set expectations when estimating software costs. The traditional business case is useful here. By comparing capital cost of development vs. benefits (either savings or additional revenue), businesses have some idea of what return to expect. In fact, many businesses insist on approving a business case before making a start on the expenditure budget.
It’s also useful to understand what the software engineers will actually be doing. Filling the time with re-inventing a feature they have implemented many times – or adding value to your project?
Best practice: Set expectations and effective architecture/coding standards to deliver high quality software in a cost-effective way.
2nd Law of Software Estimating: Estimates are Waste (or are they?)
Some argue that estimates represent 100% lost time. With this viewpoint, the time spent on estimates has no value. It does nothing to design or build the software. In addition, if estimate production is disorganised, it can often disrupt any work currently underway.
Economically, estimates for new work account between 3%-10% of the development effort. That’s a material loss of productivity – especially if only a fraction of the projects happen.
The reality is a bit more mixed than this argument first implies. As mentioned in the 1st Law of Estimates, it’s important to set expectations. Also, much of the effort required to produce an estimate is not wasted. It is essential planning that you must undertake in any case to ensure good use of resources.
Best practice: Create an estimate, but ensure that the hard work is put to good use.
3rd Law of Software Estimating: Estimates are often Competitive
It’s easy to rush an estimate, particularly when you are in a race with a competitor. Your time, plus cost per hour for the resource, produces an amount that often dictates whether you get the work or not.
Best practice: Insist on honest estimates from your technical staff. Then, apply the commercials afterwards.
4th Law of Software Estimating: Estimates are Based on Experience
If you do something hundreds of times then you will naturally become better at it. Importantly, you will be able to accurately estimate how long it will take to do it again. Also, your skill will increase quality overall – even where variations exist. Move this down to tens of times and execution is highly variable and far harder to estimate. If the task is brand-new, then execution is basically guesswork. In this case, even getting the software to work would be a measure of success.
Best practice: Automation. LEAP low-code features Robotics to perform manual tasks automatically, freeing up time and resource.
5th Law of Software Estimating: Estimates are only as good as the Requirements Statement
Broad undefined requirements produce widely inaccurate estimates. We have all seen simple projects described in massive detail while on the flip side, complex functions are reduced to a few lines.
To be effective, requirements statements should look beyond ‘known knowns.’ In addition, they should detail ‘known-unknowns.’ Finally, they need to deal with the risk of ‘unknown-unknowns’.
Best practice: Break down and number requirements. Define each requirement in terms of data scope and how the system interacts with it. Then, it’s clear when requirements change or a new one enters the frame.
6th Law of Software Estimating: Estimates carry Material Interpretation Risk
Beware high level requirement descriptions. ‘High level’ means that the implementation can be interpreted in more than one way.
Consequently, the developer will think that they have worked correctly. They will assume that another interpretation is out of scope. Whereas, the client will say that the requirement has not been interpreted correctly. They will want corrections made, believing them to be in scope. Here lies delay and extra cost.
Best practice: State your requirements clearly. Leave no room for misinterpretation.
7th Law of Software Estimating: Estimates only include Productive Hours
A development estimate is a technical estimate. It won’t include any day-to-day activities (e.g. meetings) that are part of a developer’s day.
In addition, the estimate is based on one person completing the work in a single, uninterrupted flow. This doesn’t include the involvement of any other involved parties, or the time it takes to merge their work.
If it’s critical to meet cycle time targets, then consider how this impacts the estimate, resource requirements and costs.
Moreover, the average UK software engineer is productive for around 1500 hours per year. This considers holidays, bank holidays, average sickness and non-development work. It doesn’t consider continued professional development and/or training.
Best practice: Question whether the estimate includes single or parallel working. Be aware of other factors that impact productive hours.
8th Law of Software Estimating: Estimates are Wrong
Estimates aren’t ‘Definites.’ We simply need to debate how accurate they should be.
There are three key factors that make estimates less accurate. Scale, time and project maturity.
Generally, the larger the scope, length of time to complete, or ‘newness’ all impact accuracy. This is known as the Cone of Uncertainty.
To increase the accuracy, we can do two things. First, break down the estimate into smaller elements. Then, identify and separate elements which have been completed many times before from less well known or new requirements.
Estimates get more accurate closer to the finish line
Unsurprisingly, estimates are generally more accurate the later they are made i.e. as close as possible to when the work is completed.
Compare a large project with multiple resources to be completed over a long period of time. This has many elements and subsequently, many corresponding estimates. Elements completed at the start of the project will be more accurate than those completed later on.
This is largely due to change, and the dependencies that we have introduced. To mitigate this, we can regularly re-estimate outstanding elements during the project lifecycle.
This has the advantage of keeping a regular assessment of work to be completed. However, it also reinforces the 2nd Law of Estimates (potentially time-wasting).
Best practice: Break down the project into manageable, testable, functional elements. This is essential in large projects. Ensure that your software undergoes thorough end user testing, as well as tests by the QA team.
A word to note. Even with this best practice approach, the estimate will still be wrong. This shouldn’t come as a surprise – it is a logical conclusion.
9th Law of Software Estimating: Estimates are Temporary
Like food and bad news, estimates do not age well – estimates are perishable.
This is mainly due to change. We know from the 8th Law of Estimates that estimates produced way ahead of delivery are very likely to be inaccurate. We should consider estimates as temporary for this reason alone.
Why does this happen? There are many reasons. Perhaps one element of the software is no longer needed. Or we discover new requirements (unknown-unknowns). Even more likely: fleshing out a high-level requirement (known-unknowns) leads to a higher estimate. Finally, the requirements themselves may evolve in response to changes in the marketplace.
Best practice: Understand that estimates are temporary. Be prepared to re-visit them.
10th Law of Software Estimating: Estimates are Non-Transferable
Productivity can vary by a factor of 5x between software engineers. This can be for many reasons: work ethic, experience, even typing speed/accuracy. The fact is: the estimate that you have in your hand may well be based on the output of the most capable engineer in that organisation. As such, there is a built-in bias towards higher productivity than average productivity.
Best practice: Build in estimate ranges to build-in some variation in productivity. Therefore, the expectations are set at a more realistic level.
Estimates are not Definites. Moreover, Estimates are not Targets. Finally: Estimates are likely to be modified.
Goodhart’s law states “When a measure becomes a target, it ceases to be a good measure.” When estimates become a target, then people providing the estimates will modify their behaviour.
Estimating to determine performance is not effective. Yes, we may carry out function point analysis. However, be careful to weight the costs against true impact value on the project.
What are estimates good for? Estimates are good for planning. They are helpful when you need to determine a business case in broad terms.
If your organisation truly needs to control costs and timescales, and it is essential to your project, consider a low-code solution.
Low-code platforms remove uncertainty
Low-code platforms allow businesses to implement complex business applications without much of the uncertainty. How? By basing its solutions around functional building blocks. These blocks have the following qualities:
Pre-developed, pre-tested: Each block implements bespoke requirements. It arrives ready developed and thoroughly tested. This removes 99% of the costly graft associated with coding and QA.
Configuration, not development: Changing the structure of any functional building block is a known task performed many times. Therefore, estimates to configure a solution using low-code are many times more accurate. The amount of work required is many times less. Consequently, delivery is faster.
Flexibility for change: The end solution is designed to be changed and thus has a high degree of future proofing.
Aimed at non-IT users: Low-code software development is an evolution of a process which started in the 1980s. Development environments have progressively come with more and more pre-coded libraries. As a result, developer productivity is on the rise. Many, not all, low-code platforms have progressed so much that developers are no longer required to implement a solution. That’s certainly the case with LEAP low-code powered by FLOvate.