Normal A&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&D for code you've never touched or seen. This happens a lot to me - 6 hour tasks which turn into week long mini-projects. Saying "yeah, sure that can't be too bad" 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&D work using the "usual" hours or realistic estimates, no matter how out of "norm" they are?
It used to be for me, until I made two changes to my technique.<p>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'.<p>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'.<p>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).<p>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.
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.<p>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.<p>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.
I think we all start off like that. Managing expectations is the number one game here.<p>A simple way to combat this is to just add a multiplier to whatever your instinct is telling you.<p>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.<p>If your client doesn't want any details from you, just dumb it down to your multiplier estimate.
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