4 ms·

Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their

by daanlo 6y ago

Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their marketing budget. The customer care agent that gets shouted at because feature xyz is broken / not working as the customer expects, would like to give the customer an answer when it will be fixed. The customer care manager is also worried about her team members‘ retention. So having a rough or concrete time line / roadmap is helpful for these parts of the business. I also believe that a feature request is incomplete without an estimate. It is like a friend asking you to go buy him a car. What does he need a 3000$ subaru from 2003 or a 2021 Ferrari? Of course the friend can give you an insanely accurate list of specifications, but giving you a budget + some guidelines will probably be more effective for your friend and more fun for you. Especially considering that you know much more about cars (read software) than your friend. Knowing the budget you will be able to make much better choices. If you take the allegory of a quote (which I think is correct) then you need to consider that the haggling process always also includes scope of the product. „I‘ll give you 5000$ for the car, but only if you include a free car wash“. And you can always use an estimate as defense against feature creep. „We are running low on budget, I suggest descoping xyz into the next iteration. Otherwise we won‘t be able to ship on time“. If on time is not defined then you can never have this conversation.

cheschire 6y ago
And to continue your metaphor, most software estimation comes from someone describing a car they like, and based on your mock ups you and others decide on a price, how long is acceptable to build, etc. So then you goto build the car and everything's going great till you find out that the latest research shows the specific design of engine you're using doesn't work with the eco friendly fuel that is now being mandated by the government. And suddenly killing cows is uncool so you have to change all your chairs to fabric or source fake leather, but half of your company thinks that endorsing fake leather is hide-appropriation and you're now spending a third of your time in HR going through training. And eventually you get about a week out from delivering the car and the customer calls your PM and says they want the car to have a top speed 30mph over the original specs while maintaining the fuel efficiency rating. And the doors should swing up, instead of out. Like billionaires'.
mwfunk 6y ago
Agreed, marketing (and everyone, really) needs at least rough estimates. Software is notoriously hard to predict. As time goes on, estimates get updated as more is known about the problem and the org's ability to solve it. So, by definition the first estimate anyone makes at the beginning is the least reliable one, by a long shot, but it's something to start with that gets refined as time goes on. I think where companies can get in trouble with software is when the initial rough estimate somehow gets blessed as the plan of record to cement in everyone else's critical path, and subsequent estimates are treated as engineering screwups rather than more informed predictions. I don't know what the solution is, because stuff like this can happen with everyone involved being super competent and having the best intentions. And sometimes there are engineering screwups, neither side is always blameless. Power imbalances between organizations are where natural creative conflicts go bad. In a less healthy company, whichever org is on top politically tends to be blameless, whether it's fair or not, which ultimately hurts everyone's ability to do their best work because conflicts between orgs are less likely to be resolved based on what's best for the company or project as a whole. In ideal companies, orgs are balanced such that they can push back on each other for good reasons, but not for zero-sum, shit-rolling-downhill reasons. I'm pretty sure ideal companies only exist briefly or never though.
closeparen 6y ago
I need to know what the stock market is going to do next week. Otherwise, how am I going to become a billionaire? My broker’s refusal to tell me literally costs much more than all the returns he’s ever generated. Who does he think he is?
jrumbut 6y ago
That's the thing, if other departments have a timeline they need that should be the estimate. I think it's a lot more natural in business software to say something like "we need the best version of XYZ you can do in three months" rather than saying "we need XYZ" and hoping the estimate is three months. That way everyone's cards are on the table and can work together on getting what they need.
marcus_holmes 6y ago
Kinda. Except that's "need for a definite date" is an expectation that they could be flexible about if forced. If other professions genuinely understood that software estimation is inaccurate by its nature and that accurate predictions of completion dates are, by their nature, impossible, then the uncertainty can be managed. But because it seems so simple to estimate how long a piece of work will take for everyone else, it's really difficult to get other people to realise how hard this is. I've sat in meetings saying "I don't know how long this is going to take" repeatedly until the rest of the organisation works out that they're not going to get a definitive date. Then suddenly the marketing team plans for "OK, well if it's done by this date then we'll have enough time to make this trade fair. If not then we can skip that and do the other one". They'd like to have a definite date because it makes their job easier. But if they can't have one, they can work around it. > I also believe that a feature request is incomplete without an xestimatex delivery date attached This is so true, as long as the devs have control over the scope. "We don't know and can't predict how long it's going to take to build the thing. If we can't build it all by the deadline, what's more important: delivering something on the deadline, or missing the deadline and delivering the entire feature set?" To use your car haggling analogy: You've given me $5K to buy a 4-door car less than 5 years old. If I can't find one like that, what's more important: the budget, the doors or the age?

by daanlo 6y ago

cheschire 6y ago

And to continue your metaphor, most software estimation comes from someone describing a car they like, and based on your mock ups you and others decide on a price, how long is acceptable to build, etc. So then you goto build the car and everything's going great till you find out that the latest research shows the specific design of engine you're using doesn't work with the eco friendly fuel that is now being mandated by the government. And suddenly killing cows is uncool so you have to change all your chairs to fabric or source fake leather, but half of your company thinks that endorsing fake leather is hide-appropriation and you're now spending a third of your time in HR going through training. And eventually you get about a week out from delivering the car and the customer calls your PM and says they want the car to have a top speed 30mph over the original specs while maintaining the fuel efficiency rating. And the doors should swing up, instead of out. Like billionaires'.

mwfunk 6y ago

Agreed, marketing (and everyone, really) needs at least rough estimates. Software is notoriously hard to predict. As time goes on, estimates get updated as more is known about the problem and the org's ability to solve it. So, by definition the first estimate anyone makes at the beginning is the least reliable one, by a long shot, but it's something to start with that gets refined as time goes on. I think where companies can get in trouble with software is when the initial rough estimate somehow gets blessed as the plan of record to cement in everyone else's critical path, and subsequent estimates are treated as engineering screwups rather than more informed predictions. I don't know what the solution is, because stuff like this can happen with everyone involved being super competent and having the best intentions. And sometimes there are engineering screwups, neither side is always blameless. Power imbalances between organizations are where natural creative conflicts go bad. In a less healthy company, whichever org is on top politically tends to be blameless, whether it's fair or not, which ultimately hurts everyone's ability to do their best work because conflicts between orgs are less likely to be resolved based on what's best for the company or project as a whole. In ideal companies, orgs are balanced such that they can push back on each other for good reasons, but not for zero-sum, shit-rolling-downhill reasons. I'm pretty sure ideal companies only exist briefly or never though.

closeparen 6y ago

I need to know what the stock market is going to do next week. Otherwise, how am I going to become a billionaire? My broker’s refusal to tell me literally costs much more than all the returns he’s ever generated. Who does he think he is?

jrumbut 6y ago

That's the thing, if other departments have a timeline they need that should be the estimate. I think it's a lot more natural in business software to say something like "we need the best version of XYZ you can do in three months" rather than saying "we need XYZ" and hoping the estimate is three months. That way everyone's cards are on the table and can work together on getting what they need.

marcus_holmes 6y ago

Kinda. Except that's "need for a definite date" is an expectation that they could be flexible about if forced. If other professions genuinely understood that software estimation is inaccurate by its nature and that accurate predictions of completion dates are, by their nature, impossible, then the uncertainty can be managed. But because it seems so simple to estimate how long a piece of work will take for everyone else, it's really difficult to get other people to realise how hard this is. I've sat in meetings saying "I don't know how long this is going to take" repeatedly until the rest of the organisation works out that they're not going to get a definitive date. Then suddenly the marketing team plans for "OK, well if it's done by this date then we'll have enough time to make this trade fair. If not then we can skip that and do the other one". They'd like to have a definite date because it makes their job easier. But if they can't have one, they can work around it. > I also believe that a feature request is incomplete without an xestimatex delivery date attached This is so true, as long as the devs have control over the scope. "We don't know and can't predict how long it's going to take to build the thing. If we can't build it all by the deadline, what's more important: delivering something on the deadline, or missing the deadline and delivering the entire feature set?" To use your car haggling analogy: You've given me $5K to buy a 4-door car less than 5 years old. If I can't find one like that, what's more important: the budget, the doors or the age?