Vancouver has a lot of Coal, but they also have Hydro, and IIRC, they have a nuke there
COMPLETELY wrong. Power in Vancouver is over 90% hydroelectric with the vast majority of the remainder natural gas and a small fraction diesel. They have NO coal, and BC (the province ) has no nuclear reactors.
the power is in most cases still being generated by coal or oil fired power stations in most countries, so aren't you just playing "out of sight, out of mind" games with the pollution ?
In BC (the province Vancouver is in), over 90% of the power produced is hydroelectric. Their thermal generating capacity is primarily natural gas, with a small fraction diesel. They have little if any coal or oil burning generating stations.
No. They have not yet invented the magic zero emission fossil fuel engine yet, and if they did the first installation probably wouldn't go on a Zamboni.
And then because it is new code, you have to test the entire system from scratch again, and re-establish confidence in the stability.
Every once in a while code is soo shit poor that it needs rewriting - I've had to do this myself recently with one of my ex-developers pile of *ahem* code.
But the instance we are talking about here is recoding a simple function (the example was quicksort) to do it in a few less k or a few less ms. I content that for the vast majority of applications this type of rewrite is a waste of resources and completely pointless.
And what possible difference would that make in the general case? If people spent more time actually fixing bugs and paying attention to usability issues than trying to recode sections that are working perfectly because 'the current solution is not elegant enough', a lot more software would be a lot less frustrating to use.
I'm not saying once you do the estimate based on past performance you dont add risk. Do you have a new team, is this a new language, new customer, etc. Take all the risks and for each estimate how long it will take extra if that risk actually occurs. multiply that by the probability of the risk occurring. If the risk is over 50% then remove it from the risk table and add it to your baseline schedule. Sum all these risk probabilities and present this with your original estimate. So your original schedule with factored risk is your total estimate (because some of the risks will happen). Also your total risk must be bigger than the longest unfactored risk to ensure you can cover it.
This method of task estimation is standard in all industry - there's no reason software cant be estimated in the same manner.
Seriously. I give you advice that *works* and you come back with "who died and made you king". With an attitude like that no wonder you are at odds with your supervisors.
Obviously I didn't respond with what you want to hear so here it is. You are a coding genius that can do no wrong, limited by the fact that everyone around you (except you) is a complete moron. No one else knows how to do it right except you. People enjoy your bitching and complaining because pointing out everyones idiocy in this manner makes them better people. If it wasn't for you and your genius skills, the entire company would collapse in a fit of stupidity. You are a God amongst programmers.
16 hours is way too short (at least I'm not into 50k and 100k line schedules) but tasks on the 1 day to two week timeframe is good. You can estimate any project on that scale pretty accurately.
If the scope of work is vague, then fill in the gaps yourself with your assumptions, then hand that back with your estimate.
It's obvious it's impossible to give an accurate estimate on vague requirements, so make them not vague. One of two things will happen - they will accept your estimate (so you're covered in case the requirements change later on), or they will say that the assumptions are incorrect, here's how it really is at which point you update your estimate.
Either way you are working to a real spec, and the boss knows what you are working to as well.
That's not Scrum, thats just good practice. It's far easier to estimate when you break the project down into chunks instead of trying to just guess at the whole project. Breaking it down means you have gone through the exercise of understanding the problem and how to solve it.
Anyone who submits a schedule to me should have the tasks between 1 day and two weeks duration. When I see schedule tasks on the order of months it means they don't understand the problem.
So when you realized it would take longer than the first estimate you gave did you give the new estimate to your boss or did you just wait to get fried for your first incorrect estimate?
If you provide the estimate, then "miss enough deadlines, checkpoints, tollgates, or whatever", then obviously your original estimate was crap, no matter how you justified it.
and often, that approximation of a past development event is substantially different from the project for which you want an estimate.
Then if the new project is completely different, then you cant use the past programs to estimate. One of the parameters in parametric estimating is how similar the current project is in size and complexity.
because the people who actually do software development know that using "parametric tools to estimate development schedules" means guessing the future based on an approximation of the past.
What's wrong with that? If the next project can be shown to be similar in complexity and size to previous projects, then that type of estimating should be fine. Add risk for overall, and higher risk for the proportion that is different.
Parametric estimation is used in all disciplines, not just software. There is no reason software has to be different.
If it always takes me 20-30 minutes to drive to work, then I can assume tomorrows drive will be the same. Unless of course I leave from a different location.
Then stop complaining, take the features that haven't been done, prioritize them yourself based on what you believe are the most important to get the most functionality the fastest, put a timeline on the integration and testing of each feature and present it back to the manager.
If he can't do the job, do it for him. He should be impressed with your planning abilities and willingness to take charge. If not, then he's an idiot - look for a new job.
Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.
The point is that if you were able to estimate accurately in the first place, you wouldn't be ever in the situation where you have to decide between all the features that were requested and on-time.
No, I have a Motokrzr K1. Smallest phone I could find with the features I need.
little scooter that gets me on the "information superhighway" and is good for most general day to day internet purposes
I have a computer for that. If I'm outside, I'm enjoying outside. The last thing I want is to be looking at another computer.
I play games on my phone more than I actually umm... use the phone.
I have a PS3 for that.
I wouldn't be surprised if most people start thinking about their phones as mobile computers with the ability to make calls.
When phones get to the point where they have the power of my laptop, sure. Until then it is just a toy. VERY occasionally it would be nice to have a GPS on my phone, and Google maps, but I could count those times on one hand over the past several years. I just dont want to lug around something three times the size / weight of my phone for features I never use. If I go out with the intent of doing work, then I'll bring my laptop. A phone is just too awkward of a medium to do any real work on.
As one poster pointed out, a sticking mechanical assembly would make the throttle stay at the last point your foot put it, but it would NOT cause acceleration without pressure on the pedal
Yes, who knows and we shall see. But your point is demonstrably false. If you push the accelerator down and hold it in position, the car WILL accelerate until it levels out at a new steady state speed. Until it does, the car is accelerating with a fixed pedal position.
Slashdot Mirror
Vancouver has a lot of Coal, but they also have Hydro, and IIRC, they have a nuke there
COMPLETELY wrong. Power in Vancouver is over 90% hydroelectric with the vast majority of the remainder natural gas and a small fraction diesel. They have NO coal, and BC (the province ) has no nuclear reactors.
the power is in most cases still being generated by coal or oil fired power stations in most countries, so aren't you just playing "out of sight, out of mind" games with the pollution ?
In BC (the province Vancouver is in), over 90% of the power produced is hydroelectric. Their thermal generating capacity is primarily natural gas, with a small fraction diesel. They have little if any coal or oil burning generating stations.
No. They have not yet invented the magic zero emission fossil fuel engine yet, and if they did the first installation probably wouldn't go on a Zamboni.
And then because it is new code, you have to test the entire system from scratch again, and re-establish confidence in the stability.
Every once in a while code is soo shit poor that it needs rewriting - I've had to do this myself recently with one of my ex-developers pile of *ahem* code.
But the instance we are talking about here is recoding a simple function (the example was quicksort) to do it in a few less k or a few less ms. I content that for the vast majority of applications this type of rewrite is a waste of resources and completely pointless.
And what possible difference would that make in the general case? If people spent more time actually fixing bugs and paying attention to usability issues than trying to recode sections that are working perfectly because 'the current solution is not elegant enough', a lot more software would be a lot less frustrating to use.
That should never happen. If it does, then that guy doesn't deserve to be a manager and you should look for another job.
You HAVE to work towards a plan, otherwise you are just working on a bunch of random features that may or may not be needed or work together.
I'm not saying once you do the estimate based on past performance you dont add risk. Do you have a new team, is this a new language, new customer, etc. Take all the risks and for each estimate how long it will take extra if that risk actually occurs. multiply that by the probability of the risk occurring. If the risk is over 50% then remove it from the risk table and add it to your baseline schedule. Sum all these risk probabilities and present this with your original estimate. So your original schedule with factored risk is your total estimate (because some of the risks will happen). Also your total risk must be bigger than the longest unfactored risk to ensure you can cover it.
This method of task estimation is standard in all industry - there's no reason software cant be estimated in the same manner.
Seriously. I give you advice that *works* and you come back with "who died and made you king". With an attitude like that no wonder you are at odds with your supervisors.
Obviously I didn't respond with what you want to hear so here it is. You are a coding genius that can do no wrong, limited by the fact that everyone around you (except you) is a complete moron. No one else knows how to do it right except you. People enjoy your bitching and complaining because pointing out everyones idiocy in this manner makes them better people. If it wasn't for you and your genius skills, the entire company would collapse in a fit of stupidity. You are a God amongst programmers.
I can guess that you didn't find a new job but prefer just to bitch about how stupid everyone else is in your company.
16 hours is way too short (at least I'm not into 50k and 100k line schedules) but tasks on the 1 day to two week timeframe is good. You can estimate any project on that scale pretty accurately.
If the scope of work is vague, then fill in the gaps yourself with your assumptions, then hand that back with your estimate.
It's obvious it's impossible to give an accurate estimate on vague requirements, so make them not vague. One of two things will happen - they will accept your estimate (so you're covered in case the requirements change later on), or they will say that the assumptions are incorrect, here's how it really is at which point you update your estimate.
Either way you are working to a real spec, and the boss knows what you are working to as well.
That's not Scrum, thats just good practice. It's far easier to estimate when you break the project down into chunks instead of trying to just guess at the whole project. Breaking it down means you have gone through the exercise of understanding the problem and how to solve it.
Anyone who submits a schedule to me should have the tasks between 1 day and two weeks duration. When I see schedule tasks on the order of months it means they don't understand the problem.
So when you realized it would take longer than the first estimate you gave did you give the new estimate to your boss or did you just wait to get fried for your first incorrect estimate?
If you're creating a quote for developing essentially the same software project over again, I wager that you're probably doing something wrong.
If you don't know the difference between similar and same, then you're doing something wrong.
If you provide the estimate, then "miss enough deadlines, checkpoints, tollgates, or whatever", then obviously your original estimate was crap, no matter how you justified it.
and often, that approximation of a past development event is substantially different from the project for which you want an estimate.
Then if the new project is completely different, then you cant use the past programs to estimate. One of the parameters in parametric estimating is how similar the current project is in size and complexity.
because the people who actually do software development know that using "parametric tools to estimate development schedules" means guessing the future based on an approximation of the past.
What's wrong with that? If the next project can be shown to be similar in complexity and size to previous projects, then that type of estimating should be fine. Add risk for overall, and higher risk for the proportion that is different.
Parametric estimation is used in all disciplines, not just software. There is no reason software has to be different.
If it always takes me 20-30 minutes to drive to work, then I can assume tomorrows drive will be the same. Unless of course I leave from a different location.
I tried that once. The answer? Everything!
Then stop complaining, take the features that haven't been done, prioritize them yourself based on what you believe are the most important to get the most functionality the fastest, put a timeline on the integration and testing of each feature and present it back to the manager.
If he can't do the job, do it for him. He should be impressed with your planning abilities and willingness to take charge. If not, then he's an idiot - look for a new job.
Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.
The point is that if you were able to estimate accurately in the first place, you wouldn't be ever in the situation where you have to decide between all the features that were requested and on-time.
So this may be a stupid question, but without a SIM what did you use your iPhone for?
Do you own a current generation smartphone?
No, I have a Motokrzr K1. Smallest phone I could find with the features I need.
little scooter that gets me on the "information superhighway" and is good for most general day to day internet purposes
I have a computer for that. If I'm outside, I'm enjoying outside. The last thing I want is to be looking at another computer.
I play games on my phone more than I actually umm... use the phone.
I have a PS3 for that.
I wouldn't be surprised if most people start thinking about their phones as mobile computers with the ability to make calls.
When phones get to the point where they have the power of my laptop, sure. Until then it is just a toy. VERY occasionally it would be nice to have a GPS on my phone, and Google maps, but I could count those times on one hand over the past several years. I just dont want to lug around something three times the size / weight of my phone for features I never use. If I go out with the intent of doing work, then I'll bring my laptop. A phone is just too awkward of a medium to do any real work on.
All I care about is a phone that has good audio quality so I can understand them and they me, and is small.
It's a PHONE people!!!
I think he meant even dead people have cellphones. Just like all those dead people voted for Bush.
Or if they move it. Once they do general relativity takes over and the time is now 'wrong' according to a stationary observer.
As one poster pointed out, a sticking mechanical assembly would make the throttle stay at the last point your foot put it, but it would NOT cause acceleration without pressure on the pedal
Yes, who knows and we shall see. But your point is demonstrably false. If you push the accelerator down and hold it in position, the car WILL accelerate until it levels out at a new steady state speed. Until it does, the car is accelerating with a fixed pedal position.