<story><title>Software effort estimation is mostly fake research</title><url>http://shape-of-code.coding-guidelines.com/2021/01/17/software-effort-estimation-is-mostly-fake-research/</url></story><parent_chain><item><author>daanlo</author><text>Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page &amp;#x2F; 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 &amp;#x2F; 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.&lt;p&gt;So having a rough or concrete time line &amp;#x2F; roadmap is helpful for these parts of the business.&lt;p&gt;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.&lt;p&gt;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.</text></item><item><author>didibus</author><text>The issue with estimates are expectations. While nobody acknowledges it, you&amp;#x27;re not actually asked for an estimate, you&amp;#x27;re being asked for a quote.&lt;p&gt;The difference is when you&amp;#x27;re asked for a quote, you&amp;#x27;re asked how much you will be charging, with the expectations that you&amp;#x27;ll be willing to eat into your own margins to give a lower quote. That&amp;#x27;s why it&amp;#x27;s a negotiation, where you negotiate how much extra effort, time and headcount you&amp;#x27;re willing to give, how much tech dept you&amp;#x27;re willing to take, etc., for the privilege of getting their business.&lt;p&gt;If you see it for what it really is, you&amp;#x27;ll see that it works pretty well actually. The business gets more out of you for less to them. It was never about having an accurate timeline or helping with planning or prioritizing, and always about negotiating a better contract with the dev team.&lt;p&gt;Now keep in mind that the &amp;quot;business&amp;quot; in this case is a person who need to report that through their amazing prowess of administration and management, they personally managed to get X feature out during their last review cycle at Y cost with impact Z. This person will not need to deal with developer satisfaction, retention and performance. They will not need to deal with the impact the lower margins they pushed for had on the next feature delivery, or the continued maintainance of the systems. And if the dev team had to lower the quality too much in order to meet the quote they put out, that will be 100% their fault, the &amp;quot;business&amp;quot; will know not to use them for their next contract, or they&amp;#x27;ll expect the dev team to take on fixing all the issues at their own expense once more.</text></item></parent_chain><comment><author>mwfunk</author><text>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&amp;#x27;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&amp;#x27;s something to start with that gets refined as time goes on.&lt;p&gt;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&amp;#x27;s critical path, and subsequent estimates are treated as engineering screwups rather than more informed predictions.  I don&amp;#x27;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.&lt;p&gt;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&amp;#x27;s fair or not, which ultimately hurts everyone&amp;#x27;s ability to do their best work because conflicts between orgs are less likely to be resolved based on what&amp;#x27;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&amp;#x27;m pretty sure ideal companies only exist briefly or never though.</text></comment>
<story><title>Software effort estimation is mostly fake research</title><url>http://shape-of-code.coding-guidelines.com/2021/01/17/software-effort-estimation-is-mostly-fake-research/</url></story><parent_chain><item><author>daanlo</author><text>Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page &amp;#x2F; 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 &amp;#x2F; 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.&lt;p&gt;So having a rough or concrete time line &amp;#x2F; roadmap is helpful for these parts of the business.&lt;p&gt;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.&lt;p&gt;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.</text></item><item><author>didibus</author><text>The issue with estimates are expectations. While nobody acknowledges it, you&amp;#x27;re not actually asked for an estimate, you&amp;#x27;re being asked for a quote.&lt;p&gt;The difference is when you&amp;#x27;re asked for a quote, you&amp;#x27;re asked how much you will be charging, with the expectations that you&amp;#x27;ll be willing to eat into your own margins to give a lower quote. That&amp;#x27;s why it&amp;#x27;s a negotiation, where you negotiate how much extra effort, time and headcount you&amp;#x27;re willing to give, how much tech dept you&amp;#x27;re willing to take, etc., for the privilege of getting their business.&lt;p&gt;If you see it for what it really is, you&amp;#x27;ll see that it works pretty well actually. The business gets more out of you for less to them. It was never about having an accurate timeline or helping with planning or prioritizing, and always about negotiating a better contract with the dev team.&lt;p&gt;Now keep in mind that the &amp;quot;business&amp;quot; in this case is a person who need to report that through their amazing prowess of administration and management, they personally managed to get X feature out during their last review cycle at Y cost with impact Z. This person will not need to deal with developer satisfaction, retention and performance. They will not need to deal with the impact the lower margins they pushed for had on the next feature delivery, or the continued maintainance of the systems. And if the dev team had to lower the quality too much in order to meet the quote they put out, that will be 100% their fault, the &amp;quot;business&amp;quot; will know not to use them for their next contract, or they&amp;#x27;ll expect the dev team to take on fixing all the issues at their own expense once more.</text></item></parent_chain><comment><author>cheschire</author><text>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.&lt;p&gt;So then you goto build the car and everything&amp;#x27;s going great till you find out that the latest research shows the specific design of engine you&amp;#x27;re using doesn&amp;#x27;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&amp;#x27;re now spending a third of your time in HR going through training.&lt;p&gt;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&amp;#x27;.</text></comment>