5 ms·

Software estimation is hard – do it anyway

2 points by vortex_ape 5y ago

daly 5y ago
In 50 years of programming I found: (a) time estimate are dangerous. In one case the leader of our team estimated 5 people for 5 months. The company wrote a fixed-cost contract. After 10 people for 18 months the company folded. (b) time estimates are meaningless. All of the software I worked on was new. There was no "prior art" to ground the estimate. Projects were almost always "late", mostly due to changing requirements. (c) time estimates assume a known future. Who expected the pandemic? (Or the Spanish Inquisition?). How good is your estimate when the 6 people you could "hire" are all rejects from other projects because they can't program? (d) time estimates assume a known good tool set. CorelDraw won't run on your old Mac but the company won't pay for new hardware. Microsoft pushed out a "destruction tuesday" update and now your machine won't boot. Somebody "upgraded" the library software and now your code won't compile. And don't get me started about chasing a compiler bug (I've fought 5), each costing an unplanned week. Or hardware bugs (3 times), that basically stopped the project until they were fixed. (e) time estimates will cost you time and money. Suddenly everything become a crisis. Cancel that vacation. Work nights. Work weekends. Nobody gets a raise if this is late. (f) time estimates WILL be used against you. Managers write down the "estimate", stick it in a drawer, and when "blame time" comes you can be certain to be "to blame" for a bad estimate. I know you think I'm wrong. You "just know" my "lived experience" is nonsense. You can't estimate software. Get over it. Read "The Mythical Man Month".
daly 5y ago
Just as an example, I tried to cause an LED to blink on a microcontroller. It is a trivial task. It took me 18 hours. Lots of code to install, several error messages that required hours of google searches, several obscure root-only commands to enable group access, USB recognition, board-specific code updates, etc. The online video shows that "it just works"... so the expectation is that "it just works". I did get it to work. But it took 18 hours. Explain that to the boss who watched the video. Now I'm trying to get an OLED display to work. I'm 10 hours into the game, using an oscilloscope to debug I2C signals... but, but, but, the online video shows "it just works"! Management has no clue about how complex the whole tower of code required to get anything to work. There is nothing in engineering approaching the complexity of the software eco-system. Nor is there anything that changes so rapidly ... "but it was working yesterday!" You can't estimate software. Get over it.

2 points by vortex_ape 5y ago

daly 5y ago

In 50 years of programming I found: (a) time estimate are dangerous. In one case the leader of our team estimated 5 people for 5 months. The company wrote a fixed-cost contract. After 10 people for 18 months the company folded. (b) time estimates are meaningless. All of the software I worked on was new. There was no "prior art" to ground the estimate. Projects were almost always "late", mostly due to changing requirements. (c) time estimates assume a known future. Who expected the pandemic? (Or the Spanish Inquisition?). How good is your estimate when the 6 people you could "hire" are all rejects from other projects because they can't program? (d) time estimates assume a known good tool set. CorelDraw won't run on your old Mac but the company won't pay for new hardware. Microsoft pushed out a "destruction tuesday" update and now your machine won't boot. Somebody "upgraded" the library software and now your code won't compile. And don't get me started about chasing a compiler bug (I've fought 5), each costing an unplanned week. Or hardware bugs (3 times), that basically stopped the project until they were fixed. (e) time estimates will cost you time and money. Suddenly everything become a crisis. Cancel that vacation. Work nights. Work weekends. Nobody gets a raise if this is late. (f) time estimates WILL be used against you. Managers write down the "estimate", stick it in a drawer, and when "blame time" comes you can be certain to be "to blame" for a bad estimate. I know you think I'm wrong. You "just know" my "lived experience" is nonsense. You can't estimate software. Get over it. Read "The Mythical Man Month".

daly 5y ago

Just as an example, I tried to cause an LED to blink on a microcontroller. It is a trivial task. It took me 18 hours. Lots of code to install, several error messages that required hours of google searches, several obscure root-only commands to enable group access, USB recognition, board-specific code updates, etc. The online video shows that "it just works"... so the expectation is that "it just works". I did get it to work. But it took 18 hours. Explain that to the boss who watched the video. Now I'm trying to get an OLED display to work. I'm 10 hours into the game, using an oscilloscope to debug I2C signals... but, but, but, the online video shows "it just works"! Management has no clue about how complex the whole tower of code required to get anything to work. There is nothing in engineering approaching the complexity of the software eco-system. Nor is there anything that changes so rapidly ... "but it was working yesterday!" You can't estimate software. Get over it.