3 ms·

I do pretty well at it. My method is to identify all the components of a system and individually assign how many days I think I could do it in if I was really

by edoo 7y ago

I do pretty well at it. My method is to identify all the components of a system and individually assign how many days I think I could do it in if I was really motivated. Then multiply by about 2-3 depending on your experience implementing previously similar modules. Then multiply by 2. I usually end up with a conservative time estimate where some things take longer and some shorter but overall it generally works. On this project that approach would have been... i can do it 3 weeks, give myself 6, and double it = 12. People love it when you come in at or under estimated time and really don't like it when you are late. Give yourself a buffer.

twothamendment 7y ago
That is pretty close to how I do it and I'm not the only one who thinks I'm good at it. This only works on a stack and team that I'm familiar with. It works with projects that are days, weeks or a year long. If you can't break it down you don't understand it and if you don't understand it you aren't ready to estimate it.
r41nbowdash 7y ago
i ran analysis on our codebase, most of the files had 40% rewrites, with some outliers being 90% rewritten. the file sizes followed linear distribution, usually from 100 to 2000 lines of code. when the 90% rewrite hit a larger files, it accounted for almost 50% of total effort put into development. what i got from this, for a single component i take the ideal estimate then multiple it x2, and do the same x2 project wide. there's additional friction when integrating outside components, but i'm rarely blamed for it, so i don't care that much to put it in estimates. now the hard part is selling the idea to the management, like "here are our ideal estimates, lets multiply it by 4". when doing freelance work i usually bill for the ideal estimated time multiplied by 2, the rest being my risk, on the other hand any changes in the requirements, or miscommunication is a risk of the client.

by edoo 7y ago

twothamendment 7y ago

That is pretty close to how I do it and I'm not the only one who thinks I'm good at it. This only works on a stack and team that I'm familiar with. It works with projects that are days, weeks or a year long. If you can't break it down you don't understand it and if you don't understand it you aren't ready to estimate it.

r41nbowdash 7y ago

i ran analysis on our codebase, most of the files had 40% rewrites, with some outliers being 90% rewritten. the file sizes followed linear distribution, usually from 100 to 2000 lines of code. when the 90% rewrite hit a larger files, it accounted for almost 50% of total effort put into development. what i got from this, for a single component i take the ideal estimate then multiple it x2, and do the same x2 project wide. there's additional friction when integrating outside components, but i'm rarely blamed for it, so i don't care that much to put it in estimates. now the hard part is selling the idea to the management, like "here are our ideal estimates, lets multiply it by 4". when doing freelance work i usually bill for the ideal estimated time multiplied by 2, the rest being my risk, on the other hand any changes in the requirements, or miscommunication is a risk of the client.