5 ms·

Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the

Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?

silisili 2y ago
I've pretty much found the most it scales linearly is 2, and only then in good conditions such as working well together, greenfielding, and something with clear enough boundaries. After that, well, it basically flatlines and even seems to decrease at times.
kaspm 2y ago
Efficient but not necessarily better. When I'm solo developing I go back later and I made some questionable decisions a team member would have identified.
- FridgeSeal 2y ago
  My amusing if cynic take: it’s a function of the number of opinions about how to do it. A project can tolerate 2 easily, 3 in many cases, 4 and above is difficult terrain. To scale up team count, you need to increase the count of “unopinionated, doesn’t really care devs” to prevent too many opinionated devs landing on the same part(s) of the projects and conflicting. Put one or 2 on each pillar of the project - 3 tops if they work together excellently. If a project needs more bodies, drop in unopinionated devs. There’s enough bus factor that they catch each others code, but not so much that it grinds to a halt in communication overhead.
humzashahid98 2y ago
Related to this subject is Casey Muratori's video about Conway's law and a possible extension to it. The communication overhead of working in teams, and the fact it's harder to address cross-cutting concerns in them, is a key theme in it. https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY There is also Descartes' quote about how a work produced by one master is often better than one in which many are involved, because of the unifying vision.
- ozim 2y ago
  But one master cannot go to the Moon. It takes coordinated effort of many, many people. The same with making a-bomb, the same with making anything bigger in software. It’s nice that Linus started kernel and GIT but nowadays he’s not writing much code and most likely he would is not able to review personally each and every PR.
  - humzashahid98 2y ago
    You're right. We also have proverbs like "two heads are better than one" and "standing on the shoulder of giants" so people recognise that both sides are important and have their value. Right now, I'm working on my own on a personal project attempting to do something a little novel and I appreciate being able to go back and refine my ideas/previous code based on things I learn and additional thinking (even rewriting from scratch), when I'm more likely to face friction (like "stick to the suboptimal approach; it's not that bad") and cause trouble for teammates if I was working with someone else. So the value of working alone speaks more to me currently than the value of working in teams, but they both have their place.
LordDragonfang 2y ago
I read The Mythical Man Month recently (first published in 1975), and while some of it is charmingly dated (have a secretary take your code and run it down for you!), it's astonishing how much of its discussion and advice for structuring a team of programmers remains relevant even today.
- xattt 2y ago
  As a teenager, I misread the title and borrowed it from the library. Imagine my disappointment and embarrassment when I realized that there was no mention of a human-moth hybrid at all.
deleted 2y ago
[deleted]
codebje 2y ago
Either software development teams are a wonderful metaphor for multithreaded code, or multithreaded code is a wonderful metaphor for software development teams. I'm not sure which.
- calebpeterson 2y ago
  Plot twist: the dining philosophers problem was based on a real-life software development team.
  - codebje 2y ago
    Each wants to claim a keyboard and a mouse, but due to new pair programming requirements set by management there is one fewer set of peripherals than there are developers.

Scaling software development has been THE vexing problem since day one. There's no doubt that the most efficient system fits in the head of a single person; the challenge is then what?

silisili 2y ago

I've pretty much found the most it scales linearly is 2, and only then in good conditions such as working well together, greenfielding, and something with clear enough boundaries. After that, well, it basically flatlines and even seems to decrease at times.

kaspm 2y ago

Efficient but not necessarily better. When I'm solo developing I go back later and I made some questionable decisions a team member would have identified.

FridgeSeal 2y ago
My amusing if cynic take: it’s a function of the number of opinions about how to do it. A project can tolerate 2 easily, 3 in many cases, 4 and above is difficult terrain. To scale up team count, you need to increase the count of “unopinionated, doesn’t really care devs” to prevent too many opinionated devs landing on the same part(s) of the projects and conflicting. Put one or 2 on each pillar of the project - 3 tops if they work together excellently. If a project needs more bodies, drop in unopinionated devs. There’s enough bus factor that they catch each others code, but not so much that it grinds to a halt in communication overhead.

humzashahid98 2y ago

Related to this subject is Casey Muratori's video about Conway's law and a possible extension to it. The communication overhead of working in teams, and the fact it's harder to address cross-cutting concerns in them, is a key theme in it. https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY There is also Descartes' quote about how a work produced by one master is often better than one in which many are involved, because of the unifying vision.

ozim 2y ago
But one master cannot go to the Moon. It takes coordinated effort of many, many people. The same with making a-bomb, the same with making anything bigger in software. It’s nice that Linus started kernel and GIT but nowadays he’s not writing much code and most likely he would is not able to review personally each and every PR.
- humzashahid98 2y ago
  You're right. We also have proverbs like "two heads are better than one" and "standing on the shoulder of giants" so people recognise that both sides are important and have their value. Right now, I'm working on my own on a personal project attempting to do something a little novel and I appreciate being able to go back and refine my ideas/previous code based on things I learn and additional thinking (even rewriting from scratch), when I'm more likely to face friction (like "stick to the suboptimal approach; it's not that bad") and cause trouble for teammates if I was working with someone else. So the value of working alone speaks more to me currently than the value of working in teams, but they both have their place.

LordDragonfang 2y ago

I read The Mythical Man Month recently (first published in 1975), and while some of it is charmingly dated (have a secretary take your code and run it down for you!), it's astonishing how much of its discussion and advice for structuring a team of programmers remains relevant even today.

xattt 2y ago
As a teenager, I misread the title and borrowed it from the library. Imagine my disappointment and embarrassment when I realized that there was no mention of a human-moth hybrid at all.

deleted 2y ago

[deleted]

codebje 2y ago

Either software development teams are a wonderful metaphor for multithreaded code, or multithreaded code is a wonderful metaphor for software development teams. I'm not sure which.

calebpeterson 2y ago
Plot twist: the dining philosophers problem was based on a real-life software development team.
- codebje 2y ago
  Each wants to claim a keyboard and a mouse, but due to new pair programming requirements set by management there is one fewer set of peripherals than there are developers.