Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.
What I can get running in a weekend for my personal use would:
- take 20 days (10x) to turn into something that other teams in the same company can easily consume without much effort on their part
- take 200 days to turn into a public facing product that people would actually use instead of their current thing
IMO, this is why engineers so often look at products and think "Oh, I can build that in a weekend"
I've created plenty of toy languages and reactive UI libraries in a weekend. People may find inspiration and take some ideas from my 2 days of work but nobody is going to use those as a replacement for their current thing without the next 198 days of effort.
A small example: if you can create a "spreadsheet to website generator" in a few hours, it'll be a month before you've built it out enough to launch a product around it that will attract users.
In 10 hours, I can make something that looks starts to look valuable to my wizened eyes. This is the happy path.
In 100 hours, I can build something that the rest of my team can begin to see the value in. This is the MVP.
In 1000 hours, I can make something that I can actually sell to a customer - but only with clear expectations that there may be months or years of on-going polishing required. The is the beta.
In 10000 hours, I was able to learn this perspective. No product is ever done. You only ever get to that tenuous beta phase and then becomes almost entirely about dealing with customer feedback.
For me personally, I start to check out after the 100 hour stage of development. Tedium and repetitive concerns begin to leak in and tempt the strategic nuclear problem solving facilities with insane overkill solutions (aka abstraction hell). I now try very hard to find reasonable handoff strategies before I get to that point. There are other team members who cannot stand the indeterminism of the 0-100 hour range of development, so this works out really well in our shop. Setup the pattern, let the tool operator zone out for the duration of their shift. Not everyone wants to be ivory tower architect and can find far more joy in the simpler tasks.
And for academic work in particular, going from "prototype good enough to get numbers out of" to "product someone can reliably use" is a huge amount of effort, along which there are zero papers.
EDIT: Here's a summary:
A program is just a set of instructions that seems to do what you want. All programmers say "Oh, I can easily beat the 10 lines / day cited by industrial programmers." They are talking about just coding something, not building a product.
A product (more useful than a program):
* can be run, tested, repaired by anyone
* usable in many environments on many sets of data.
* must be tested
* documentation
Brooks estimates a 3x cost increase for this.
To be a component in a programming system (collection of interacting programs like an OS):
* input and output must conform in syntax, semantics to defined interfaces
* must operate within resource budget
* must be tested with other components to check integration (very expensive since interactions grows exponentially in n).
Brooks estimates that this too costs 3x.
A combined programming system product is 9x more costly than a program.
https://www.cs.usfca.edu/~parrt/course/601/lectures/man.mont...