It shouldn’t come as a surprise that everything we build has a timeline associated with it. It may be strictly defined from the get-go, or it may just be reviewed at the end. An easy back on the napkin equation to figure out if something is “worth” building is:

Building cost + ongoing expenses < Significant profit within a certain period

The within a certain period here is important. If the potential profit is greater than the building cost, but it takes 15 years to realize that profit, it may not be worth working on the idea.

But, what defines how much something costs? Usually, it’s calculated as the sum of:

• Raw material
• Tools
• Worker(s) time cost
• Generic resources

In software engineering, most of the “raw materials” are the engineer’s time.

Why are we so bad at estimating timelines?

I’ve heard from more than one Civil Engineer that it isn’t uncommon for a building deadlines to be missed due to various reasons. A common reason is that sometimes not everything is taken into account when going through the requirements. Basic things like such as time needed for cement to dry. Now remember, we’ve been building shelters since the dawn of man. We needed shelters before we could create fancy paintings on the walls of caves. The art of building shelters is a few thousand old, and we still suck at estimating civil building projects...so imagine how bad we are at estimating an art that isn't even 100 years old! There is also a whole new universe when we’re talking about software: You can’t touch software, and even seasoned developers can’t fully imagine it before it is built.

Now let’s do an exercise:

Imagine a chair that you may want to build
Estimate how long it may take

I could bet my left hand that you imagined a chair that you’ve seen somewhere. Every time we want to build something new we are fated to compare it with a previous experience.This is the biggest challenge in software estimating; even experienced developers can rarely compare one software with another.

Different types of project estimation:

Ballpark

Objective: Get a basic idea without going too deep into the details

When to use it?: When the client wants a vague idea of how long it would take to build the product and we don’t have details such as:

• scope
• Design
• User stories

When to use it?: If possible, never use it. I can’t stress how dangerous this option is for a client. If we ever offer this one as a possibility they will want to stick with it; it doesn’t matter if we have a contract saying that this was just to get an idea. They won’t understand, and in the end, they will want to pay for time outlined in the estimate. A ballpark estimate will always need to lead to a proper estimate afterwards, so you might as well just start with a proper one.

Full estimation

Objective: Get an estimate that is as closest to reality as possible, can’t be trusted, but gives a basic idea.

When to use it?: If possible, every time.

Required information

When we are estimating a project we need the following information:
Although we don’t need all the user stories we indeed need the main ones, here is an example of ours that we used for creating a security app called BovedaHQ.:

• The user signs up -> he sees a dashboard with a list of keys sent, keys received and the number of available keys
• The user is on the home page -> he clicks "send key" and a modal opens where he can set the details and hit "send"
• The user is in the dashboard -> he clicks "read" and a modal with the key value appears
• We need a feature list of what needs to be implemented If the client has any tech stack preference, we need to know beforehand

Common questions

How much time does it take to estimate a project?

Like everything in software engineering, the answer is “it depends”. Here at Codelitt, we build projects of all sizes, and as you can expect, if the project has more features, it takes more time to estimate it. It also depends on the complexity of the features. The estimating process goes like this:

• The sales team gathers the requirements and together with a PM they break them into a feature list.
• The PM goes through the feature list explaining each case with the developers involved.
• No less than two developers go through the feature list estimating what needs to be done, and there’s any doubt the ask the PM, which in turn may ask sales to get more info from the client. After the estimates are done we have two possible cases:
  The difference range between them is smaller than 20%, and if so it is good to go.
  The difference range between them is bigger than 20%, and if so the devs need to get together to understand each other’s vision and come up with a closer estimate that makes sense to both of them.

With all this in mind, an estimate usually will take around 1-3 days. We’ve done estimates in as little as a couple hours and at most a couple days.

How to approach a feature estimate

A feature estimate is more art than science, and it is very common to see two devs having different values. Usually, it happens because people have different backgrounds and experiences. What may be seen as easy for one can be hard for another. When estimating, we should go through the following checklist:

• Have you built this before?
• Is this an integration? If so do you have control over it? e.g., you don’t have control over twitter API
• Do you have all the information you need?
• What can go wrong?
• How much time will you need if everything goes well?
• How much time will you need if the worst case happens?
• If a web application, does it have a mobile and desktop version?
• If a mobile application, is it native or hybrid?

I once remember a gnarly project manager say that plans and estimates were like a lettuce, good for a couple of days, rather wilty after a week, and unrecognizable after a couple of months. - Martin Fowler