<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>durandal1</author><text>Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams.  It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there&amp;#x27;s no magic.  While there are teams within apple that does scrum&amp;#x2F;agile, none of the core OS&amp;#x2F;frameworks teams does it AFAIK, and I do think it&amp;#x27;s incompatible with shipping on a hardware-aligned schedule.</text></item><item><author>jakubp</author><text>If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who&amp;#x27;d love to have this :)&lt;p&gt;My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software development, that there seems to be no sane way to compare what happened with original estimates. (new features, changed features, lots of new information, market shifts&amp;#x2F;product vision shifts, quality assumptions change, etc. etc.)&lt;p&gt;But at that point nobody cares! People go on with further projects, and no data is ever collected.&lt;p&gt;Nobody learns.&lt;p&gt;When f*ckups happen, i.e. a gross over- or under-estimate, this is often not shared with the broader organization (ashamed&amp;#x2F;afraid sales people&amp;#x2F;PMs&amp;#x2F;devs say nothing&amp;#x2F;hide it&amp;#x2F;sugarcoat it). Client walks away.&lt;p&gt;Sometimes project is severly underestimated but usually not just because of the software part. Again, no decoupling and estimation of contributing factors is done.&lt;p&gt;It&amp;#x27;s insane.</text></item></parent_chain><comment><author>trimbo</author><text>Have you noticed their declining OS release quality in recent years? I have, and I now wait 6 months to upgrade.&lt;p&gt;The triangle is real[1]. Something&amp;#x27;s gotta give when a deadline can&amp;#x27;t move, and as we know from Brooks, software development speed doesn&amp;#x27;t increase linearly with more people. So it&amp;#x27;s primarily quality or scope that must suffer to hit a software deadline.&lt;p&gt;[1] - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Project_management_triangle&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Project_management_triangle&lt;/a&gt;</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>durandal1</author><text>Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams.  It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there&amp;#x27;s no magic.  While there are teams within apple that does scrum&amp;#x2F;agile, none of the core OS&amp;#x2F;frameworks teams does it AFAIK, and I do think it&amp;#x27;s incompatible with shipping on a hardware-aligned schedule.</text></item><item><author>jakubp</author><text>If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who&amp;#x27;d love to have this :)&lt;p&gt;My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software development, that there seems to be no sane way to compare what happened with original estimates. (new features, changed features, lots of new information, market shifts&amp;#x2F;product vision shifts, quality assumptions change, etc. etc.)&lt;p&gt;But at that point nobody cares! People go on with further projects, and no data is ever collected.&lt;p&gt;Nobody learns.&lt;p&gt;When f*ckups happen, i.e. a gross over- or under-estimate, this is often not shared with the broader organization (ashamed&amp;#x2F;afraid sales people&amp;#x2F;PMs&amp;#x2F;devs say nothing&amp;#x2F;hide it&amp;#x2F;sugarcoat it). Client walks away.&lt;p&gt;Sometimes project is severly underestimated but usually not just because of the software part. Again, no decoupling and estimation of contributing factors is done.&lt;p&gt;It&amp;#x27;s insane.</text></item></parent_chain><comment><author>virgilp</author><text>Adobe executes (executed) massive releases on a well-defined cadence (1.5 yr per &amp;quot;creative suite&amp;quot;). Sure, I won&amp;#x27;t say they don&amp;#x27;t have collaboration, or top-tier engineers etc. But in the end, the success of this well defined cadence boiled down to the simple strategy of &amp;quot;we release what is ready&amp;quot;. Everybody knew the deadlines well in advance, and  everybody strives to &amp;#x27;make it&amp;#x27;  - but, (not so) occasionally, some teams didn&amp;#x27;t and you could see entire features get ruthlessly cut out. Simply no other way of synchronizing across the entire company... you cut scope to make it in time, and if you can&amp;#x27;t make it, that&amp;#x27;s it, your feature gets cut. With enough teams working, you still get features to showcase at each release.</text></comment>