3 ms·
Software Development time estimation. Is it a problem that needs solving?
I am curious to know if time estimation is still a difficult problem to solve for developers. In my experience I am either way under, or overprice. I feel like I should get paid the overpriced fee, but clients then go into a price war with me.
Has anyone solved this with tooling or is it an "experience thumbsuck"? What is your method?
- elviejo 4y ago1st start by reading: Software Estimation: demistifying the black art" by McConell. They also have online classes with the same content. If you do that you will be better than 80% of devs at estimating. After that read about Montecarlo simulation on software projects.
- reggieza 4y agoThank you for the suggestions. I am curious, do you think there is a way to normalise estimations in the industry? What I typically see happen is the following: 1) I charge $2k and need 5 days to do a Stripe integration 2) You need 1 day and charge $1k Many factors are at play, for instance availability and experience I presume. Would it be beneficial for us to go to a crowsourced chart and lookup the average integration time for Stripe based on 100's of votes? It seems to be quite open information in other engineering faculties.
- perelin 4y agoFrom what I read between the lines you work as an external contractor bidding on one-off client projects/tasks. In that case estimation is even harder, because you often dont know the quality of the code base that you have to work on. I would always try to get a "times and material" agreement, where you are just paid by the hour and estimations are only necessary for rough scheduling and are not bound to your paycheck. This of course implies a certain level of trust that you need to have with your clients. Often this is the case on longer term /regular engagements. If you need to bid / pitch to a new client you might be forced into a "fixed price" offer for a certain scope. Best to avoid but if you cant I would try to explicitly have some form agreement that allows for some form of re-estimation, e.g. if some explicit (or implicit) assumptions dont hold to be true. On the matter of estimations: I would try to avoid single-person, one-point estimations (e.g. "3.5 days!") and would try to aim for a three-point or range estimation with some confidence levels (e.g. "best case 1.5 days if all assumptions hold; 3-5 days if we encounter some unknown unknowns, 6-12 days if we totally missed something in the requirements and spec"). Best try to partner up with somebody to get a second opinion about assumptions and risk. The most solid projections (not estimations) I have seen, were by stable teams who just counted their work-item throughput and learned to be good at item sizing.