The problem with estimates
There is a good reason why we no longer work on fixed bid projects at Ombu Labs, it’s impossible to estimate with certainty in a startup environment.
Uncertainty
Entrepreneurs want to build something that has never been built before. How can you estimate something like that?
Only if you have built something similar, you can estimate with some certainty. Even then, you will be off by 2x, 3x, 5x or more!
At work, sometimes we help entrepreneurs fix bugs or add features to their existing projects. That doesn’t make our estimates any better because their existing projects are new to us. We are not familiar with the code.
We don’t know what we will find once we see the code. It’s a known fact that there will be a learning curve. Unfortunately, the time spent ascending the curve will directly depend on the quality of the code.
When you are about to take over a project, usually you don’t have enough time to analyze the code and use that analysis as a multiplier of the complexity of the project that you’re getting into.
Lately we have been performing free code quality reports for our potential clients. This helps, but it just improves our guesses.
All of these problems cause uncertainty, which will mess up your estimates.
Fear
On the other hand, you are afraid that:
- You will overestimate and the client won’t want to work with you because there is someone who will do it in half the time (or so they claim)
- You will underestimate. You will work late nights, you will lose money, and the client won’t be happy.
Depending on how badly you want this client, you will go for one or the other.
If you overestimate, you will definitely follow Parkinson’s Law. If you underestimate, you will sleep less. It’s your choice. In rare cases you will get the estimates right.
—
Entrepreneurs will usually want to know how much it will take to build feature x. You will only be able to estimate accurately once you have experience with the programming language, framework, code base, domain, feature, interfaces and expectations.
Until then your estimates will be way off.
In order to come up with the best estimates, you should always determine the work breakdown structure of feature x and estimate piece by piece. The smaller the piece the better.
Your estimates should include a best case and worst case scenario:
- Worst case scenario: The code base that you’re taking over is a total mess. Spaghetti code, no code coverage, hard to understand, which makes it all extremely complex.
- Best case scenario: The code base is clean, simple, well designed and it has decent test coverage and documentation, which makes it easy to take over.
Personally, I don’t like to work with estimates. Every time I work on something, I want to finish it as soon as possible, keeping quality high, writing an elegant solution, being as pragmatic as possible.
Hopefully, your clients won’t take your estimates as a promise, they will take it as your best guess.