

Ask HN: Is underestimating a chronic IT project problem? - antonpug

Normal A&amp;D time allocated in my department is 6 hours. That may be enough, if you know what is going on, the code involved and potential dependencies affected. But sometimes you are given 6 hours to A&amp;D for code you&#x27;ve never touched or seen. This happens a lot to me - 6 hour tasks which turn into week long mini-projects. Saying &quot;yeah, sure that can&#x27;t be too bad&quot; only to realize that I have no idea what is going on in the 35 files, 3 namespaces, countless methods I am supposed to understand.<p>Do you encounter this in your work, and how do you deal with it? Do you estimate A&amp;D work using the &quot;usual&quot; hours or realistic estimates, no matter how out of &quot;norm&quot; they are?
======
_sh
It used to be for me, until I made two changes to my technique.

1\. Give a confidence value: 'this can be completed in x hours with 50%
confidence, or y hours with 85% confidence (where y > x)'. If you don't want
to work in 'confidence percentages', translate that to a range: 'this can be
completed in x/2 - x*1.5 hours'.

2\. Never, ever quote on something you've never done before. Does the project
require using a new API? Write a small, isolated test application that uses
the API in similar ways. This will sharpen your confidence value. If you don't
have time to exercise all the parts of the project you've never done before,
shrink your confidence value but explain why: 'this can be completed in x
hours with 20% confidence, but with a little more preparation time, I can get
you a more accurate quote'.

Most importantly: be professional with your quotes. Don't take on too much
just to be the hero who moved mountains and saved the day. No-one will thank
you if you do (after all, you're just doing your job), and your professional
image will take a dent when you don't. Also, as soon as you realise you can't
make your confidence value, don't keep it to yourself. Yes, you'll piss people
off by lagging the project, but the alternative is much worse. Not speaking up
when issues arise is an ego problem (similar to being the hero who moved
mountains).

Yes quoting is hard, but is required. Don't worry, developers are not the only
ones who struggle with it. I work for a (non-software-) engineering firm that
is currently taking a $1.6M+ bath (and rising by the hour) because they
botched the quote process. Shit happens all the time.

------
jaynate
Ah, I see. Perhaps you can use Analysis & Design tasks not to estimate the
actual work, but further research tasks necessary to get to a more solid
answer. Setting the expectation that all issues can be analyze and designed in
6 hours seems arbitrary.

Many times the Analysis and Design of a solution encompasses trying things out
and actually experimenting with changes. By the time you're done with Analysis
and Design you've virtually implemented the solution. Of course there is the
documentation and reviews that you could also estimate separately.

This is a classic human problem - we suck at estimation. And if some pointy
haired boss is demanding perfect estimates, you should give him or her good
estimates for the next piece of work you can predict rather than the finished
task.

------
agibsonccc
I think we all start off like that. Managing expectations is the number one
game here.

A simple way to combat this is to just add a multiplier to whatever your
instinct is telling you.

To add to what _sh was saying, the confidence value is a good idea. If you can
explain to your client that you think it could take 3 weeks, but let's set
expectations for 6 assuming some things go wrong, you're going to be a lot
better off and have some breathing room. If you finish earlier, all of a
sudden you're awesome.

If your client doesn't want any details from you, just dumb it down to your
multiplier estimate.

------
antonpug
Analysis & Design? Looking at the problem at hand, looking at the code we
have, what can be done to implement what the business wants, access the
impacts to other layers of the application, document everything, set up
reviews

------
jaynate
Can you clarify what A&D is?

