5 ms·

Acorn was a curious company. It managed to get incredible amounts of work done, by assigning big projects to individuals instead of teams. My memory is not to b

by ajb 2y ago

Acorn was a curious company. It managed to get incredible amounts of work done, by assigning big projects to individuals instead of teams. My memory is not to be relied on at this lapse of time, but I seem to recall that in the final years there was a browser maintained by one guy, a port of Java by two, and an implementation of directX by another. Obviously all those projects were much smaller back then (around 98) but still, those devs were doing the work of what another company had a team to do. And in fact this does work, as communication overhead is reduced, but in many cases the increase in productivity loses strategically to the slower time to market.

beeboobaa3 2y ago
From personal experience it's amazing how much more productive I am on solo projects vs working with other people. When you're solo you can just go, but in a team everything needs to be discussed or at least communicated.
- DowagerDave 2y ago
  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.
- VelesDude 2y ago
  Old joke but - Two engineers can do in two months what one engineer can do in one month. But this sort of goes with the African proverb, "If you want to go fast, go alone. If you want to go far, go together."
- deleted 2y ago
  [deleted]
beachy 2y ago
Obligatory Fred Brooks quote: "The bearing of a child takes nine months, no matter how many women are assigned.”
- exe34 2y ago
  Hah, try getting them to sit through refinement meetings, and I bet it'll take a lot longer!
fidotron 2y ago
I recall seeing a Macromedia Director player but never heard of a DirectX port. In any case the lack of hardware floating point in most of their machines was looking like a big mistake by the mid 90s. Their compilers were also way off the pace and that was getting to be a problem. Tbh I think I am slightly bitter about having stuck with Acorn a bit too much, and should have jumped away sooner. It is clear Acorn knew they were toast even before the Risc PC. A lot of these very impressive developments were consequently glorious wastes of time, which is kind of tragic too.
- ajb 2y ago
  I'm not sure if the directX port ever saw the light of day. At that point the top brass were putting their hopes in the 'Network Computer' [1] and Set Top Boxes, so it may have shipped with one of those, or been intended to. [1]https://en.wikipedia.org/wiki/Network_Computer_Reference_Profile https://en.wikipedia.org/wiki/Network_Computer_Reference_Pro...
  - VelesDude 2y ago
    The NC is one of those things that feels like it was simply to far ahead of where the technology and the mind set of users was. Nowadays it would have much more traction thanks to SaaS. In tech, one step ahead is an innovator. Two step ahead is a martyr.
    - ajb 2y ago
      Yeah, this was back in the days of dial-up. Chromebooks are effectively the modern NC
      - VelesDude 2y ago
        A great example. Chromebooks also managed to also take the better ideas of Netbooks and go with them.
    - flomo 2y ago
      Trivia at this point. But the Oracle Network Computer was a low-end x86 box running FreeBSD and a full-screen Netscape Navigator. Very much a product of its time. (WebTV, later purchased by Microsoft, was the more successful product in this space.)
gedy 2y ago
> but in many cases the increase in productivity loses strategically to the slower time to market. I disagree that it always means slower time to market - if the individual is empowered and minimum process (no PMs, "grooming", estimates, etc) a sharp individual can run circles around a full team.
- ajb 2y ago
  Well, "many cases" isn't "always". A bigger team will get there faster if the development is larger than a certain size, if it's smaller then an individual can win.

by ajb 2y ago

beeboobaa3 2y ago

From personal experience it's amazing how much more productive I am on solo projects vs working with other people. When you're solo you can just go, but in a team everything needs to be discussed or at least communicated.

DowagerDave 2y ago
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.
VelesDude 2y ago
Old joke but - Two engineers can do in two months what one engineer can do in one month. But this sort of goes with the African proverb, "If you want to go fast, go alone. If you want to go far, go together."
deleted 2y ago
[deleted]

beachy 2y ago

Obligatory Fred Brooks quote: "The bearing of a child takes nine months, no matter how many women are assigned.”

exe34 2y ago
Hah, try getting them to sit through refinement meetings, and I bet it'll take a lot longer!

fidotron 2y ago

I recall seeing a Macromedia Director player but never heard of a DirectX port. In any case the lack of hardware floating point in most of their machines was looking like a big mistake by the mid 90s. Their compilers were also way off the pace and that was getting to be a problem. Tbh I think I am slightly bitter about having stuck with Acorn a bit too much, and should have jumped away sooner. It is clear Acorn knew they were toast even before the Risc PC. A lot of these very impressive developments were consequently glorious wastes of time, which is kind of tragic too.

ajb 2y ago
I'm not sure if the directX port ever saw the light of day. At that point the top brass were putting their hopes in the 'Network Computer' [1] and Set Top Boxes, so it may have shipped with one of those, or been intended to. [1]https://en.wikipedia.org/wiki/Network_Computer_Reference_Profile https://en.wikipedia.org/wiki/Network_Computer_Reference_Pro...
- VelesDude 2y ago
  The NC is one of those things that feels like it was simply to far ahead of where the technology and the mind set of users was. Nowadays it would have much more traction thanks to SaaS. In tech, one step ahead is an innovator. Two step ahead is a martyr.
  - ajb 2y ago
    Yeah, this was back in the days of dial-up. Chromebooks are effectively the modern NC
    - VelesDude 2y ago
      A great example. Chromebooks also managed to also take the better ideas of Netbooks and go with them.
  - flomo 2y ago
    Trivia at this point. But the Oracle Network Computer was a low-end x86 box running FreeBSD and a full-screen Netscape Navigator. Very much a product of its time. (WebTV, later purchased by Microsoft, was the more successful product in this space.)

gedy 2y ago

> but in many cases the increase in productivity loses strategically to the slower time to market. I disagree that it always means slower time to market - if the individual is empowered and minimum process (no PMs, "grooming", estimates, etc) a sharp individual can run circles around a full team.

ajb 2y ago
Well, "many cases" isn't "always". A bigger team will get there faster if the development is larger than a certain size, if it's smaller then an individual can win.