4 ms·

I remember reading an essay by Brookes, where he makes the distinction between a "program", which can basically only be used by the one who wrote it (or with th

by gwd 3y ago

I remember reading an essay by Brookes, where he makes the distinction between a "program", which can basically only be used by the one who wrote it (or with their help); a "product", which can be used by anyone; and a "system", which is more general-purpose and reliable. His point was that the first is fairly easy for one person to do in their spare time; the last often takes years of polish, debugging, extensions, and so on. 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.month.html#:~:text=A%20product%20(more%20useful%20than,must%20be%20tested https://www.cs.usfca.edu/~parrt/course/601/lectures/man.mont...

rednab 3y ago
The way I've explained this to coworkers and stakeholders is, "A prototype costs 1x, a product costs 3x, and a platform costs 9x." Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.
- hgsgm 3y ago
  3 is far too small.
  - didgetmaster 3y ago
    Agree. 10x at each stage is more realistic.
- skeeter2020 3y ago
  I've built a few products from idea to commercial software, and IME Brooks was being generous, as anecdotally I always pegged it at closer to 4x, but then I'm slow. It's actually really surprising how few product managers (forget about developers!) don't seem to know this, yet they also tend to push out the initial release way too far, so you get half a product late, then move on to the next thing.
P_I_Staker 3y ago
IME 10 lines of code can easily take 1-2 weeks, if you include all that. I agree that's a bad average time, but I'm assuming other work responsibilities, and perhaps more red tape than HN is used to.
tantaman 3y ago
I've found it to be 100x 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.
- bob1029 3y ago
  I think this tracks very close to my experience. 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.
  - johncch 3y ago
    Thank you for saying this. I'm currently in the 100h phase and I'm struggling to explain it and you said it beautifully.

by gwd 3y ago

rednab 3y ago

The way I've explained this to coworkers and stakeholders is, "A prototype costs 1x, a product costs 3x, and a platform costs 9x." Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.

hgsgm 3y ago
3 is far too small.
- didgetmaster 3y ago
  Agree. 10x at each stage is more realistic.
skeeter2020 3y ago
I've built a few products from idea to commercial software, and IME Brooks was being generous, as anecdotally I always pegged it at closer to 4x, but then I'm slow. It's actually really surprising how few product managers (forget about developers!) don't seem to know this, yet they also tend to push out the initial release way too far, so you get half a product late, then move on to the next thing.

P_I_Staker 3y ago

IME 10 lines of code can easily take 1-2 weeks, if you include all that. I agree that's a bad average time, but I'm assuming other work responsibilities, and perhaps more red tape than HN is used to.

tantaman 3y ago

I've found it to be 100x 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.

bob1029 3y ago
I think this tracks very close to my experience. 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.
- johncch 3y ago
  Thank you for saying this. I'm currently in the 100h phase and I'm struggling to explain it and you said it beautifully.