Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks.
Like if you're the type who always underestimates try to double your score each time.
doesnt this make you look bad? Time is very valuable to the clients and I believe we are billed by the hour, so therefore the more time the task takes then it'll discourage the client? (just pure speculation, i actually have no idea, I have <1 year worth of experience in my job, also first job)
I don't have much experience either, and yes it will potentially look bad, but I think saying you'll get something done in 1 day and spending 4 days is worse than just saying it'll be done in 4 days and doing it in 4 days.
Like if you're the type who always underestimates try to double your score each time.
doesnt this make you look bad? Time is very valuable to the clients and I believe we are billed by the hour, so therefore the more time the task takes then it'll discourage the client? (just pure speculation, i actually have no idea, I have <1 year worth of experience in my job, also first job)
I don't have much experience either, and yes it will potentially look bad, but I think saying you'll get something done in 1 day and spending 4 days is worse than just saying it'll be done in 4 days and doing it in 4 days.
Not that I know more than you guys after my first internship… but I've always had mega problems with estimating times for myself in all walks of life, and from what I've seen, it looks WAY better to say 'six days' and finish in four than it does to say 'three days' and finish in four. I've started to just try to overestimate everything by 50% - that way you don't look bad if you fuck it up (if you're fucking up by more than 50% then either you didn't know what you had to do or you're just being stupid to try and look good) and you also don't seem like you're incompetent for guessing 3x what everyone else would for that task
On September 02 2014 11:24 icystorage wrote: for the software engineers, how do you deal with estimates? I wasnt taught about it in college (even though i majored in software engineering) but probably because its pretty dynamic? How do you give estimates that doesnt make you look bad (estimating a very huge time for a task)? If you give a pretty short deadline it would also doesnt give you any leeway. What factors should you consider in giving an estimate on a task(s)?
I'm responsible for time estimates for myself and my team, so this is something I do lot of.
Before I give an estimate on a project I break it down into small chunks and give the architecture a bit of thought. Usually we have existing design patterns in place so it's pretty straight forward, and if not I'll grab some of the guys with the relevant experience and we'll figure it out.
After I know what we're building, and how we're building it, I figure out who's doing what. I figure out what engineers on my team are available, and then work with them to figure out who will build what.
Now I know what we're building, how we're building it, and who's doing what. Given that I've worked these guys for 6 months I know how quickly they get things done so it's actually pretty straight forward. Don't forget about test coverage, UAT, and planning for a safe release (with rollback ability).
The most important thing is to communicate changes in the timeline if you run into an un-expected challenge. Sometimes it's as mundane as an engineer not feeling well, other times you discover performance issues and have to re-architect the whole thing.
From my experience (15y now) giving timing estimates is hard, and with more experience it remains difficult.
When being asked how much time will something take, always take your time to reflect upon it, or request time to calulate it. Once your say a number, that number is out. Even if they say "just give us a number, we won't pin you down on that" be damn sure about what you say. And don't be afraid to say "I need more time to calculate that".
E.g. I'm working on a project right now where I got asked how long it will take, as a rough estimate. I said approx. 8 days. The project manager tells the client, hey it will take about 8 days, the client understands it will be done in 8, and 6 days later I got asked if they can start testing and I'm like.. wtf? In this case the unkown factor was the project manager. I worked with him for the first time, and if I would have know that he tells my estimate as a fact, I would have gone higher.
In the end, stating a higher number isn't bad, as long as you don't overdo it. If I have problems estimating a task or project, what I usually do is break the task down into smaller chunks and try to calculate that. In the end add it together, and ontop of that, add extra time for testing, debugging, communication & coordination, and if required documentation. And when you have that number, add the amount of x. And that is the magic number for unknown variables, or unexpected stuff happening. For me that's usually around 10-20%.
The bonus of breaking it down is that you can use that list as your reference and check while working on the project if you meet your estimates. And if you don't, the next time you can change it accordingly and our estimates will get better.
Thank you for giving your insights regarding estimation. This has totally fucked up my first project since I blindly estimated it without really breaking it down. I will base my future estimates from what I read here Really helpful
Estimate each part to your best ability, if you've tried the task before. Otherwise, my rule of thumb is that I multiply the hours by two.
Then I take the full estimate and multiply by pi.
I've had a situation where I had to do a small embedded system which literally was 50 lines of code, which took around 2 hours to write, and then it took 5 days to make it integrate well with the physical system it was controlling. I did *no* coding.
But it's easily transferable to software - you write the software in 2 hours, then you spent 5 days setting up the environment it has to run in... Never forget to factor in things that aren't directly related to your task. If you're working for a client they most likely haven't thought of it either or they have their own convoluted systems you need to integrate into.
On September 02 2014 11:24 icystorage wrote: for the software engineers, how do you deal with estimates? I wasnt taught about it in college (even though i majored in software engineering) but probably because its pretty dynamic? How do you give estimates that doesnt make you look bad (estimating a very huge time for a task)? If you give a pretty short deadline it would also doesnt give you any leeway. What factors should you consider in giving an estimate on a task(s)?
I'm responsible for time estimates for myself and my team, so this is something I do lot of.
Before I give an estimate on a project I break it down into small chunks and give the architecture a bit of thought. Usually we have existing design patterns in place so it's pretty straight forward, and if not I'll grab some of the guys with the relevant experience and we'll figure it out.
After I know what we're building, and how we're building it, I figure out who's doing what. I figure out what engineers on my team are available, and then work with them to figure out who will build what.
Now I know what we're building, how we're building it, and who's doing what. Given that I've worked these guys for 6 months I know how quickly they get things done so it's actually pretty straight forward. Don't forget about test coverage, UAT, and planning for a safe release (with rollback ability).
The most important thing is to communicate changes in the timeline if you run into an un-expected challenge. Sometimes it's as mundane as an engineer not feeling well, other times you discover performance issues and have to re-architect the whole thing.
While the information you provided is valuable, I don't think you answered the question directly. That was a very "political answer". How do you do estimates once you've deconstructed the project?
Since you have project manager experience I would assume you want your estimates to be accurate. How do you deal with cases where people seem to underestimate or overestimate? Do people have to often stay late when they underestimate? Do you/managers ask for an explanation for overestimates?
Lesson I learned is don't be too eager in estimating, I'm just going to triple my initial estimates because I suck at them :') Meeting deadlines late looks really bad, making deadlines earlier looks great.
On September 02 2014 13:24 WolfintheSheep wrote: Isn't it like a Golden Rule that any estimates should be done with the assumption that Life absolutely despises you and everything you do?
Yes, yes it is. I recently had an issue where a database wasn't properly loading data on startup, so I had to write a bat file to query the db via a stored proc then stick that into a .csv and type it back out to com(first 5 and last 5 lines). Thought it would take a 20 mins top...
On linux ofc it would be no problem - but it was a wintel host so no head command took me best part of 4 hours to get it to work correctly.
12 times longer than I originally thought it would take... also the hatred of windows grows stronger every day
Clean Coder by Uncle Bob touches on a lot of subjects about being a professional, estimation being one. If you haven't read the book, its not a bad read. It's not quite as good as Clean Code, but, it's good enough to be helpful. I especially enjoyed the chapters on saying no.
They discuss using this technique for estimation. I have used it a few times, and it seems okay...if I could just remember to use it more often.
i wish you could expand parameter packs like this in cpp (the sought after, but invalid, expansion is marked with brackets):
template<class... t_n,class t_i> some_t function(t_i&& value){ switch(value.index){ case index_of<[t_n],t_n...>::value:{ some_functionality dependant on types in t_n };[...] }
result
template<class... t_n,class t_i> some_t function(t_i&& value){ switch(value.index){ case 0:{ some_functionality dependant on t_0 }; other cases case i:{ some_functionality dependant on t_i }; other cases case (n-1):{ some_functionality dependant on t_(n-1) }; }
would be so insanely sweet and fast for mux / variant / vistiable type classes.
similarly (only one expansion here, so don't have to mark the one i'm after)
I've been on agile projects for the last couple years. Basically everything is chunked into a story "as x I want to be able to do y," which is then detailed into tasks. After tasking, it's pointed on a fibonacci scale, where the higher the number the less certain you are about how long it'll take and generally also means it's at higher risk of slipping. How long each point to changes based on the team, but the point is to be consistent.
Once you've done an approach like this for a period of time, it gets relatively easy to approximate how long something will take and how much bandwidth you and your team has. Importantly, by splitting everything into stories and then tasking out each story, it's a lot easier to make an estimation because you've teased out most of the requirements and hurdles.
Underestimating is usually worse than overestimating because it throws off timelines to a greater degree (people end up waiting because they're dependent and expected it to finish days ago, etc), but consistently overestimating is also bad.
EPT
I'll think about what you said
but I've always had mega problems with estimating times for myself in all walks of life, and from what I've seen, it looks WAY better to say 'six days' and finish in four than it does to say 'three days' and finish in four. I've started to just try to overestimate everything by 50% - that way you don't look bad if you fuck it up (if you're fucking up by more than 50% then either you didn't know what you had to do or you're just being stupid to try and look good) and you also don't seem like you're incompetent for guessing 3x what everyone else would for that task
