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:
In software engineering, most of the “raw materials” are the engineer’s time.
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.
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.
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:
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.
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.
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.:
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:
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:
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
Download our Incubator Resources
WANT MORE?
We’re known for sharing everything!
HANDBOOK
Save more time, get more done!
FREE HANDBOOK
Innovate from the inside
YOU MIGHT ALSO LIKE