6 ms·

> tackling more complex problems This is the 'induced demand' argument. As perfection seems impossible, and mistakes inevitable, this seems likely. However, t

> tackling more complex problems This is the 'induced demand' argument. As perfection seems impossible, and mistakes inevitable, this seems likely. However, the more I look into issues, the more I realize that a very small number of errors introduced early on is what ultimately causes a plethora of them. Just fixing a very small amount of these mistakes would have untold effects on computing over the long-term. That is, if we can get over the initial switching costs. > small team of engineers It took 2 men to over-take thousands creating Unix over Multix. It took Linus Torvalds - just about alone - a week to create git. We have already seen this prophecy come true. As teams get bigger, communication sales factorially, and the more people you have the more mistakes you make, which increases the size exponentially with each further mistake. What Unix and git showed is that when you put everything into a small team of engineers heads, they can work through the complexity enough until they can do it themselves. > Frameworks One of the things I realized a while ago is that pure/impure and library/framework have a decent mapping between the two. If you have a framework, you give it code and it acts for you, just like impure code. And so the problem we keep running into, is instead of inverting the flow like 'hexagonal architecture' says, we keep piling impure onto impure onto impure. Hexagonal says to not do anything of substance, keep the adapter clean, but each framework sure is doing something. Each layer on the stack we go up, the harder it is to get down. So now we have OS and applications and containers and k8s running micro-services that ends up being run in a web browser, when all we really needed was microkernals.

pjscott 4y ago
> As teams get bigger, communication sales factorially, That sounds a bit drastic. Surely at worst the scaling is quadratic?
- thyrsus 4y ago
  You are correct, but quadratic is sufficiently bad.
- retcon 4y ago
  Correct, sales does have to scale factorially to the development man years. That's the problem with the prevailing economic contradiction. See Jamie Dimon, JPM, three days ago.. I've never witnessed a bulge bracket chief concluding the most public statements with, roughly, "doh, I dunno, it's crazy" before. My father cut his banking teeth in the Great Depression. That was actually much more simple. (Whether because the tools of the trade were more simple or just thankfully..) "Hurricane" is the search term for Dimon's delivery...
- ItsMonkk 4y ago
  The number of channels is exponential, that's just Metcalfe's law. The ability to suss-out meaning behind those channels and come to a shared understanding pushes it to factorial. If A is speaking to B and C, A needs to also think about what communication is happening between B and C, and this is different to what B knows about C and C knows about B. In a carefully balanced classroom you might manage to get everyone knowing the same things, and this will allow knowledge to scale. Think about how much better TV got once they knew that viewers would watch every episode. What happens in software is that specialization quickly comes into play such that this is impossible in any organization that doesn't use mob programming. Other people might as well be speaking a different language. Next time you are in a Sprint meeting, think about how much you don't understand. Even as the team lead or architect who designs the entire system and whose job it is to understand everything it will be a shocking amount - it's black boxes all the way down. You'll claim that you can't know everything and that anyone who tries will fail. And this is made worse as the only true way to learn something is to do it, and if you aren't actually challenging yourself on something, anything you learn without doing will just fade away - as Spaced Repetition shows. The bigger the team, the bigger the software, the more inevitable the collapse.
  - pjscott 4y ago
    > The number of channels is exponential, that's just Metcalfe's law. Metcalfe's law is quadratic rather than exponential -- O(n^2), not O(2^n). And if n people all need to be aware of communication happening between every pair of them (which is a worst-case), then that should just add a factor of n, bringing it up to cubic. (On an unrelated and less pedantically nitpicky note, one of the most valuable professional skills I've developed is an ability and willingness to dive into black boxes. It's remarkable how many bugs arise from the interaction of two or more pieces of software with no overlap between their developers. Debugging those can involve a long, agonizing back-and-forth between people who know how X works and people who know how Y works -- or it can be over in a jiffy if you can quickly familiarize yourself with the basic internal workings of both. Past a certain point nobody can know everything, it's true, but this doesn't need to be as crippling for productivity as a lot of people allow it to be.)
    - 4y ago
vlovich123 4y ago
This seems like a fantasy considering how big the development teams for these projects are. Multics did not have thousands of developers. Linus was just more practical about software development, was maybe better at building a community, and more importantly focused on x86 commodity HW which was a bet that only Microsoft also happened to make.
- bluedino 4y ago
  It was also already built. The clone is easier to make
- retcon 4y ago
  The cumulative system design contributing to MULTICS, however, probably was a order of magnitude greater work than the implementation effort. On the shoulders of Giants may be clichèd , but it also seems increasingly as if the contemporary world has decided to deprecate inherited wisdom. Blame awful policy decisions starting under Regan..
- ItsMonkk 4y ago
  Oh, you're right. I had in my head "A combination of MIT, Bell Labs and GE" and manually translated that to thousands but it was actually only about a hundred dedicated people. Thanks.
jareds 4y ago
Although it may have only taken a week to create the initial version of Git the amount of polish and documentation required to get it to something someone like me who's not a kernel developer was a lot more than a week's worth of work. You may be able to get 80% of the functionality in 20% of the time but it's that last 20% of functionality that gives software enough polish to actually be used by someone who doesn't have an incredibly specific reason to figure out how to use the unpolished software.
7thaccount 4y ago
I thought Linus based Linux off of Minix, but used a monolithic kernel to keep things practical.

pjscott 4y ago

> As teams get bigger, communication sales factorially, That sounds a bit drastic. Surely at worst the scaling is quadratic?

thyrsus 4y ago
You are correct, but quadratic is sufficiently bad.
retcon 4y ago
Correct, sales does have to scale factorially to the development man years. That's the problem with the prevailing economic contradiction. See Jamie Dimon, JPM, three days ago.. I've never witnessed a bulge bracket chief concluding the most public statements with, roughly, "doh, I dunno, it's crazy" before. My father cut his banking teeth in the Great Depression. That was actually much more simple. (Whether because the tools of the trade were more simple or just thankfully..) "Hurricane" is the search term for Dimon's delivery...
ItsMonkk 4y ago
The number of channels is exponential, that's just Metcalfe's law. The ability to suss-out meaning behind those channels and come to a shared understanding pushes it to factorial. If A is speaking to B and C, A needs to also think about what communication is happening between B and C, and this is different to what B knows about C and C knows about B. In a carefully balanced classroom you might manage to get everyone knowing the same things, and this will allow knowledge to scale. Think about how much better TV got once they knew that viewers would watch every episode. What happens in software is that specialization quickly comes into play such that this is impossible in any organization that doesn't use mob programming. Other people might as well be speaking a different language. Next time you are in a Sprint meeting, think about how much you don't understand. Even as the team lead or architect who designs the entire system and whose job it is to understand everything it will be a shocking amount - it's black boxes all the way down. You'll claim that you can't know everything and that anyone who tries will fail. And this is made worse as the only true way to learn something is to do it, and if you aren't actually challenging yourself on something, anything you learn without doing will just fade away - as Spaced Repetition shows. The bigger the team, the bigger the software, the more inevitable the collapse.
- pjscott 4y ago
  > The number of channels is exponential, that's just Metcalfe's law. Metcalfe's law is quadratic rather than exponential -- O(n^2), not O(2^n). And if n people all need to be aware of communication happening between every pair of them (which is a worst-case), then that should just add a factor of n, bringing it up to cubic. (On an unrelated and less pedantically nitpicky note, one of the most valuable professional skills I've developed is an ability and willingness to dive into black boxes. It's remarkable how many bugs arise from the interaction of two or more pieces of software with no overlap between their developers. Debugging those can involve a long, agonizing back-and-forth between people who know how X works and people who know how Y works -- or it can be over in a jiffy if you can quickly familiarize yourself with the basic internal workings of both. Past a certain point nobody can know everything, it's true, but this doesn't need to be as crippling for productivity as a lot of people allow it to be.)
  - 4y ago

vlovich123 4y ago

This seems like a fantasy considering how big the development teams for these projects are. Multics did not have thousands of developers. Linus was just more practical about software development, was maybe better at building a community, and more importantly focused on x86 commodity HW which was a bet that only Microsoft also happened to make.

bluedino 4y ago
It was also already built. The clone is easier to make
retcon 4y ago
The cumulative system design contributing to MULTICS, however, probably was a order of magnitude greater work than the implementation effort. On the shoulders of Giants may be clichèd , but it also seems increasingly as if the contemporary world has decided to deprecate inherited wisdom. Blame awful policy decisions starting under Regan..
ItsMonkk 4y ago
Oh, you're right. I had in my head "A combination of MIT, Bell Labs and GE" and manually translated that to thousands but it was actually only about a hundred dedicated people. Thanks.

jareds 4y ago

Although it may have only taken a week to create the initial version of Git the amount of polish and documentation required to get it to something someone like me who's not a kernel developer was a lot more than a week's worth of work. You may be able to get 80% of the functionality in 20% of the time but it's that last 20% of functionality that gives software enough polish to actually be used by someone who doesn't have an incredibly specific reason to figure out how to use the unpolished software.

7thaccount 4y ago

I thought Linus based Linux off of Minix, but used a monolithic kernel to keep things practical.