Software by Numbers

What Hacker News says

1. mindcrimeFeb 2023
   One approach is to do the "per project" thing and wildly pad the charge to allow for uncertainty. This can protect you from losing money on a project that goes poorly, and can yield a big windfall on projects that go very well. But it can result in quotes that scare prospects away, and still can't guarantee that you don't lose money in the worst case.

   Another option is to do the "per project" thing, do really extensive requirements analysis up-front, and then be absolutely rabid about enforcing the change control policy. Since one of the biggest reasons for uncertainty is changing requirements, make absolutely sure that your contract reflects a "if you change anything from the initial requirements then we re-negotiate the budget" mindset. The details of you how express that can be pretty varied, of course.

   You can also combine those two options.

   Is any of this a good idea? It's arguable. People have been working this way for a very long time, but both approaches, or the combination can easily lead to adversarial relationships between vendor and customer, and can result in a lot of acrimony and antagonism.

   Arguably a better approach is to adopt the idea of "Agile Contracts"[1][2][3][4]. One problem with this is simply that it's a newer approach and something that a lot of people aren't as familiar / comfortable with. Selling customers on this approach may take some extra work. But it might just be worth it.

   There's a lot more that could be said about this, but it's not easy to condense into a quick HN post. FWIW, a few books that might be worth reading as well include:

   1. Software by Numbers[5]

   2. The Economics of Iterative Software Development[6]

   3. Software as Capital[7]

   [1]: https://en.wikipedia.org/wiki/Agile_contracts

   [2]: https://agilecontracts.org/

   [3]: https://www.contractworks.com/blog/three-types-of-agile-cont...

   [4]: https://www.scaledagileframework.com/agile-contracts/

   [5]: https://www.amazon.com/Software-Numbers-Low-Risk-High-Return...

   [6]: https://www.amazon.com/Economics-Iterative-Software-Developm...

   [7]: https://www.amazon.com/Software-Capital-Economic-Perspective...

   Show morethread
2. mattmcknightMay 2009
   There are good thorough discussions of these topics in David Anderson's "Agile Management for Software Engineering" http://www.amazon.com/Agile-Management-Software-Engineering-... and similar concepts in Software by Numbers http://www.amazon.com/Software-Numbers-Low-Risk-High-Return-...

   I think it's odd to suppose that fixing time and budget as opposed to fixing scope/requirements needs to result in different management practices from a PMI, SOX or any other perspective. It seems that fixing scope would be more dangerous from an accounting perspective, because it is so difficult to estimate cost to complete.

   Show morethread