<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>snarf21</author><text>The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward.&lt;p&gt;These days, I only give estimates in terms of &lt;i&gt;units&lt;/i&gt; but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1&amp;#x2F;4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. &amp;quot;How much money is this contract for? What date will it be signed?&amp;quot;</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>dkarl</author><text>&amp;gt; Even houses always go over time and money and that is fairly straight forward.&lt;p&gt;This is an incredibly important point.  I was &amp;quot;raised&amp;quot; in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn&amp;#x27;t do estimation and planning, and building was the favorite comparison.  A $100 million building couldn&amp;#x27;t run late or over budget.  That would be unimaginable, and it doesn&amp;#x27;t happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses.  Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn&amp;#x27;t know regular expressions and now you did.&lt;p&gt;The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren&amp;#x27;t laughed out of the room.  Elaborate heavyweight processes, and their &amp;quot;lightweight&amp;quot; (hah!) cousins, could sell themselves as proven, established solutions.  We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.</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>snarf21</author><text>The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward.&lt;p&gt;These days, I only give estimates in terms of &lt;i&gt;units&lt;/i&gt; but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1&amp;#x2F;4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. &amp;quot;How much money is this contract for? What date will it be signed?&amp;quot;</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>corry</author><text>&amp;#x27;I really wish we would treat sales people the same way. &amp;quot;How much money is this contract for? What date will it be signed?&amp;quot;&amp;#x27;.&lt;p&gt;In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting.&lt;p&gt;In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc).&lt;p&gt;Engineering is obviously different... what&amp;#x27;s the measure? LOCs? Obviously not...&lt;p&gt;Edit: just to be clear, I&amp;#x27;m saying that well-run sales teams and well-run engineering teams probably have a lot in common,  not that they are exactly the same.</text></comment>