<story><title>“Laws” of software estimation for complex work (2021)</title><url>https://mdalmijn.com/p/11-laws-of-software-estimation-for-complex-work</url></story><parent_chain><item><author>2d8a875f-39a2-4</author><text>The CTO and CPO weren&amp;#x27;t estimating the time to build the feature, they were estimating the number they needed to win the business. Successfully - job done by the C-suite.&lt;p&gt;The job of the author wasn&amp;#x27;t to build the feature in the X weeks, it was to manage the customer while the project completed in whatever time it took. He was successful too, even though he doesn&amp;#x27;t seem to realise that was his primary value-add.&lt;p&gt;The customer didn&amp;#x27;t want or expect an X week delivery of specific scope, they wanted to sign on vague requirements that they could change as the project went along while keeping the vendor under pressure to deliver whatever thing they eventually found out that they wanted.&lt;p&gt;All of the hand-wringing in the article about estimation misses the point entirely.</text></item></parent_chain><comment><author>alkonaut</author><text>They didn&amp;#x27;t seem to communicate to the author the critical bit of information then (i.e. &amp;quot;we have no intent of actually building this to these requirements in 12 weeks&amp;quot;). I get that there may be a business charade going on where impossible requirements and deadlines are juggled, but the key for the CTO here is not to simply pass that down to the team delivering, no matter how tempting that may be. His job is not only to get the deal, it&amp;#x27;s also to protect a functioning team.&lt;p&gt;The result of failing to do so is a team fighting uphill to deliver an impossible goal. So long as the CTO&amp;#x27;s &lt;i&gt;actual&lt;/i&gt; plan is delivered to me, I have no problem with it. But too often the project evolves into negative pressure and &amp;quot;crunch time&amp;quot; to meet the impossible goal. Differences between actual goals and &amp;quot;paper goals&amp;quot; are blurred. If that&amp;#x27;s what&amp;#x27;s going to happen, I&amp;#x27;d want no part of it. In fact, if the goals are sufficiently unrealistic I&amp;#x27;d tell the CTO to clearly communicate with the customer what&amp;#x27;s realistically achievable in 12 weeks, or find another developer (Yes this has been a successful approach for 20 years and counting).</text></comment>
<story><title>“Laws” of software estimation for complex work (2021)</title><url>https://mdalmijn.com/p/11-laws-of-software-estimation-for-complex-work</url></story><parent_chain><item><author>2d8a875f-39a2-4</author><text>The CTO and CPO weren&amp;#x27;t estimating the time to build the feature, they were estimating the number they needed to win the business. Successfully - job done by the C-suite.&lt;p&gt;The job of the author wasn&amp;#x27;t to build the feature in the X weeks, it was to manage the customer while the project completed in whatever time it took. He was successful too, even though he doesn&amp;#x27;t seem to realise that was his primary value-add.&lt;p&gt;The customer didn&amp;#x27;t want or expect an X week delivery of specific scope, they wanted to sign on vague requirements that they could change as the project went along while keeping the vendor under pressure to deliver whatever thing they eventually found out that they wanted.&lt;p&gt;All of the hand-wringing in the article about estimation misses the point entirely.</text></item></parent_chain><comment><author>jimmySixDOF</author><text>Yes, all very true; and in some cases you may extend the client role motivation down further into their own organization to fund the project in the first place through a fractal of self similar patterns.   Looked at from deep enough in the client organization - the contractor CTO&amp;#x2F;CPO and the Client&amp;#x27;s own PMO are all just &amp;#x27;that project&amp;#x27; and have the same commitment pressures.</text></comment>