Ideas from the team


5 Reasons Why Predicting Software Timelines Can Be Tricky

Here's 5 reasons why it's so tricky to predict software timelines.

If you’re not a software developer or engineer, you might wonder why software releases or timelines get moved. There have been lots of case studies that have shown how difficult is it to predict how long software projects are going to take, and while there are lots of new theories about development timelines such as sprints and agile development, it’s still very tough to do accurately.  

Here are just a few obstacles that our team at Spektrix often run into and how they go about solving them.

1. It’s impossible to estimate the unknown

Whenever someone is creating something new, it’s going to be tricky to know how long the process will take. All software is unique, so while you may be able to estimate the time based on previous projects, you won’t be able to predict all the complexities that could slow things down along the way. So in software development, estimates are really just educated guesses that get updated as the project moves along.

One way to be more accurate with software estimations (and one that the Spektrix team have used in the past) is planning poker. Members of the team make estimates by playing a numbered card face-down on a table, instead of speaking them aloud. The cards are then revealed and everyone talks about the answers. This helps avoid the cognitive bias of anchoring, which basically means that the first person’s number would set a precedent for everyone else’s estimates.

Our Spektrix engineers often rely on the experience of team members to make good estimates. The more an engineer knows about the domain and the software they’re building on, the better their estimations will be, so it’s important for them to tap into the knowledge of those with the most experience.

2. Engineer estimates are sometimes optimistic

When an engineer makes an estimate, they think in terms of coding hours and tend to estimate for the best case scenario. They’re thinking about solutions so naturally want to take the positive outlook that the code will work as planned. Sometimes this is true, but often unexpected issues will get in the way. If their plan is too strict, it’s unlikely they’ll be able to finish everything in time so the solution is to add contingency to your estimates.

This is where experience comes in useful again. A project manager, or in the case of team Spektrix, the Director of Engineering, will review estimates from the team and help predict how much contingency time needs to be added. It’s not possible to plan what the extra time will be needed for yet, but it’s better to safely allow for errors or difficulties than run way over an estimated time. The more uncertainty there is in the estimate, the more contingency will be added.

The extra time is also to allow for overheads, such as discussions with colleagues, absences, training, etc. Our engineers at Spektrix work out how many equivalent days' development work they can do in a week based on recent experience. Typically it's about three days development work for a five day week. This way, they have a better idea of how to convert a number of days of effort into calendar days.

3. Estimations aren’t continually assessed

While engineers will try to plan for as many obstacles as possible, it’s not possible to plan everything that comes up. That’s why estimates need to be continually assessed and updated as the system development progresses. It’s normal for new requirements to come to light as a development project progresses, and this will of course have an impact on the timeline.

So how do we deal with changes to requirements? The team here work by using some principles from Agile estimation methods. They work in sprints, which are short bursts of work (typically two to four weeks), with the idea that we can estimate what can be done in relatively small periods of time much more easily and accurately than trying to estimate six months, for example.

They will reassess after each sprint in order to plan the next one. The big question is what to do about high level, long term estimates for roadmaps and releases. Agile theory says to decide how much time you have, do the most important things first and deliver what you have when the time runs out. Obviously this isn’t always appropriate, and our team don’t tend to work in that way. However, our team do follow the idea of doing the most important aspects of the development process first. Often in a project or a release, there will be some features or additions that in a worst case scenario can be left out if they are tight for time and need to get a release out. That's why Spektrix users get final confirmation of what’s included within a release in the notes that we send out a few days before the system is upgraded. Fortunately we are able to move the changes the team didn’t have time to add in, into the next release.

4. More engineers won’t necessarily make things move faster

There’s a well known development idea that a 30-day project won’t be completed in 1 day by 30 engineers. Adding more engineers to a late project will most likely make it even later because the existing team spend their time getting the new engineers up to speed. Although the idea that more people won’t speed up a project seems illogical, the law of diminishing returns applies to most industries.

Just because more engineers are involved it doesn’t mean the development process will be faster. Think of building software in the same way as building a brick wall. You can have more than one bricklayer on it, but at a certain point they will get in each other’s way and could end up building bits of wall that don’t meet up, unless you spend time coordinating the work. Within an engineering team, everyone needs to make sure they are on the same page as everyone else. Any time an engineer creates or changes something, it could have an impact on someone else’s work so everyone has to keep communication channels open.

There are a number of tasks that can be done at the same time in parallel with each other and the team here at Spektrix splits up feature work to stop people tripping over each other changing the same code. However, there does come to a point where everyone must work as a team to piece everything together.

5. It’s hard to know how much time will be needed for fixing things

While engineers will spend a lot of time writing new code, typically problems are discovered when it’s tested. It’s impossible to predict how many software bugs there will be or how long they will take to fix, as we talked about in a previous post. Adding more time on the end of a project is necessary for this, as it’s another factor that could slow things down before a deadline.


Developing new software as well as updating and fixing software is about estimated guesses based on experience. Learning from the past and looking to the future is the best way to move forward with software planning, and although it’s difficult at times, it’s always better to get things right no matter how long it takes.

Images found here.