5 ms·

> I disagree because time estimation in software is not a useful activity. Anyone who can say this has the privilege of being fully insulated from revenue gene

by fipple 8y ago

> I disagree because time estimation in software is not a useful activity. Anyone who can say this has the privilege of being fully insulated from revenue generation. But at some level of the company, resourcing decisions are made, and they depend on understanding the costs and benefits of various tasks. If you are deciding between having your engineering team build an Android app and adding an API integration, you need to understand how much revenue it will bring you and how much it will cost, and that’s where estimation comes into play. Man months are very non mythical when it comes time to write paychecks.

mlthoughts2018 8y ago
> “Anyone who can say this has the privilege of being fully insulated from revenue generation.” You are incorrect. I work in a directly client-facing capacity and often have phone calls to help our actual clients and their product managers, and I have many internal stakeholders for my team’s work that are sales-facing and client-facing. Most of the quarterly planning meetings I am required to give input into are directly focused on revenue generation. Because software velocity estimates do not have any correlation to the actual delivery timeline, yet they will be used for political bikeshedding by people who don’t know about the technival details, it is exactly in revenue critical situations that you want to get rid of the pretense of estimation and admit the truth that you have to simply measure by doing and frequently reporting blockers.
- fipple 8y ago
  If you can’t at least say which of two projects will take longer, the architecture must be fucked to hell.
  - mlthoughts2018 8y ago
    Usually it is sociological, and has not much to do with good or bad architectures. The more surprising blockers tend to happen when someone on another team can act as a gatekeeper to a resource you need, like permission to make a change, and uses this blocking for some political purpose. It can cause bang-simple engineering tasks to take weeks, during which time you never know how much longer you’ll need to wait, and depending on political capital of the entity blocking you, you may not even be allowed to publicly explain they are blocking you, and you are forced to absorb the negative externalities of their choice to block you.
lovich 8y ago
What you've said is true in the same way that if you could just estimate the winning lottery numbers for me, we could increase revenue drastically. Even though it would be incredibly useful to have, it is effectively impossible to give an accurate value other than for trivial or massively constrained problems.
taneq 8y ago
Even insulated from revenue generation, things have to get done and you need to let people know when that will happen. Estimation is difficult, yes, but it's vital for working in teams of more than one person.

by fipple 8y ago

mlthoughts2018 8y ago

> “Anyone who can say this has the privilege of being fully insulated from revenue generation.” You are incorrect. I work in a directly client-facing capacity and often have phone calls to help our actual clients and their product managers, and I have many internal stakeholders for my team’s work that are sales-facing and client-facing. Most of the quarterly planning meetings I am required to give input into are directly focused on revenue generation. Because software velocity estimates do not have any correlation to the actual delivery timeline, yet they will be used for political bikeshedding by people who don’t know about the technival details, it is exactly in revenue critical situations that you want to get rid of the pretense of estimation and admit the truth that you have to simply measure by doing and frequently reporting blockers.

fipple 8y ago
If you can’t at least say which of two projects will take longer, the architecture must be fucked to hell.
- mlthoughts2018 8y ago
  Usually it is sociological, and has not much to do with good or bad architectures. The more surprising blockers tend to happen when someone on another team can act as a gatekeeper to a resource you need, like permission to make a change, and uses this blocking for some political purpose. It can cause bang-simple engineering tasks to take weeks, during which time you never know how much longer you’ll need to wait, and depending on political capital of the entity blocking you, you may not even be allowed to publicly explain they are blocking you, and you are forced to absorb the negative externalities of their choice to block you.

lovich 8y ago

What you've said is true in the same way that if you could just estimate the winning lottery numbers for me, we could increase revenue drastically. Even though it would be incredibly useful to have, it is effectively impossible to give an accurate value other than for trivial or massively constrained problems.

taneq 8y ago

Even insulated from revenue generation, things have to get done and you need to let people know when that will happen. Estimation is difficult, yes, but it's vital for working in teams of more than one person.