"That is because the people involved ... were first rate programmers who understood what they were doing."
Well that's right, but it's the clause at the end that is doing the work. A first rate programmer isn't just somebody with good knowledge of the mechanics of programming. Yes, it is helpful to understand technicalities - lambdas, closures, whatever - but the main point is to understand the business problem to be solved, and how to cast that into software. And the problem that most organizations struggle with is that they consider software development to be low-value and they want to put their people who understand the problems in high-value roles. Then the software people don't understand what the "business" people want, and the business people don't understand (and aren't motivated) to give the software people the understanding they need.
I think this is an excellent point. I can at least say that on the software design side, we absolutely emphasize the importance of domain knowledge. But we often don't get the access we need to the experts with that knowledge. And, even when we do, that doesn't guarantee fruitful information exchange because, well, people are people.
I do know of an example of a trading firm where they trained their programmers how to trade as much as their actual traders. It's super common for startups to be cross-functional across the board by necessity in their beginnings. But it's an approach I've seen work in big firms that believe in it. I'm sure one could extend one of Beer's cybernetic diagrams to include an element 'Shared Mental Model' and then define it as one kind of method (transducer?) for preserving variety between developers and users.
As an old software jobber, I have found myself thinking a lot about information flows between people in ways I really didn't before Dan's book. Even when I'm just trying to get somebody to agree on what to put on a pizza.
That's very interesting. I've seen shops that use train programmers as a source of potential traders, but never ones that train programmers on trading with the goal of making them better programmers.
>how many managers are aware of the research done into the relative effectiveness of programmers? They should be. The best are anything from ten to twenty times as good as the worst
This is a great point, although it runs converse to the main thesis.
Computers can do wonderful things if they have wonderful people running them.
I feel like modern management (at least here in the US) is allergic to the idea that some individual humans are really good at their jobs. They'd rather have replaceable human resources. I think a lot of the AI hype is to allow people to do complicated jobs without any specialized training or experience.
It pretty much has to be allergic to the idea, since you can't operate an organisation at scale without working out how to make effective use of the non-superstar workers.
I suppose the question I would have for Beer is “Why do you suppose this has not happened in the past 50 years? Surely someone would write a computer program to run a small business that would be hyper efficient by standards of the day and proceed to take over the world. Why didn’t that happen?”
Now, I think the best rejoinder is “Amazon pretty much did”, but I note that it isn’t quite the way Beer is imagining things.
We might say Shein have done a lot of it too - although you might quite fairly reply also not quite the way Beer imagined things. I think one can also make the case that Toyota got quite far down the track he is describing - and I think this reveals one of the issues - really he is thinking of manufacturing.
LLMs might hold out the possibility of extending beyond manufacturing - but they might also not really be ready yet for it. (And possibly without further architectural innovation, not ever.)
Yea, you can get pretty far with manufacturing planning with computers, but even there actual optimization is a real bear to get going, as the data maintenance becomes monstrous and the question of how close your computer model actually cleaves to your physical process becomes a big problem. I've worked in supply chain and operations planning for nearly 20 years now implementing MRP systems, and almost always the correct answer is "don't try to do finite scheduling" unless you have a very sophisticated organization with a lot of people to stay on it. Arguably, it might require more humans to keep things going with the computer doing finite scheduling than letting humans do it for many firms. You absolutely could not have gotten there before the 2000's, and even today the mainstream ERP systems are not great at it, although many smaller firms offer better bolt on options.
Beer was writing in an era of mainframes and minicomputers. But since he survived to 2002, he saw computers become personal, portable, and with a vast quantity of interesting software that is light years from quantitative management information systems. The problem, if any, is resistance to change (like housebuilding designs) and a failure to visualize how business could change (resistance of managers). Interestingly, innovative software design remains marginalized for some reason, whether engineers are resistant to change, lack imagination, or their corporate bosses lack imagination.
What was Beer's great insight? The nested command and control system based on cybernetics. As the Chile experiment showed, he was really pushing for an automated, real Socialism that would have benefited the USSR command economy. Western countries steered well clear of that losing approach, and we can see the result. Yes, the problems you outline in your excellent book still exist, and just maybe cybernetics and better management structure designs could alleviate some of those problems, although the examples often refer to large corporations with deep management hierarchies - the same problems that large national democracies face with a central government that maintains overall control.
Did Beer ever reflect on his famous ideas and change his mind, especially as IT has so changed over his lifetime?
Totally tangential to the post topic - but I was interested by the reference to Leibniz's mathesis universalis. Did Beer study philosophy -- or at least history of ideas? Possibly it just comes through history of maths.
Coordination of IRS data and immigration court appointment status has made it more efficient to harass, detain, deport and assault one segment of America's workforce and intimidate others. I guess this matters - who writes the programs and what she plans to do with the data.
Werner Von Braun really wanted his rockets to go to Mars but he was OK with using them to bomb London. He was, however, not too keen to learn about the slave labor that built them.
Before they got real power, techies thought computers could be used for cute things like storing recipes, or playing Pac Man. Now that they have power, they think tech should be used to get more of it.
Did you watch the scene in "2001" where the proto-human realizes a bone can be used as a club to kill? That's about where we are.
"That is because the people involved ... were first rate programmers who understood what they were doing."
Well that's right, but it's the clause at the end that is doing the work. A first rate programmer isn't just somebody with good knowledge of the mechanics of programming. Yes, it is helpful to understand technicalities - lambdas, closures, whatever - but the main point is to understand the business problem to be solved, and how to cast that into software. And the problem that most organizations struggle with is that they consider software development to be low-value and they want to put their people who understand the problems in high-value roles. Then the software people don't understand what the "business" people want, and the business people don't understand (and aren't motivated) to give the software people the understanding they need.
I think this is an excellent point. I can at least say that on the software design side, we absolutely emphasize the importance of domain knowledge. But we often don't get the access we need to the experts with that knowledge. And, even when we do, that doesn't guarantee fruitful information exchange because, well, people are people.
I do know of an example of a trading firm where they trained their programmers how to trade as much as their actual traders. It's super common for startups to be cross-functional across the board by necessity in their beginnings. But it's an approach I've seen work in big firms that believe in it. I'm sure one could extend one of Beer's cybernetic diagrams to include an element 'Shared Mental Model' and then define it as one kind of method (transducer?) for preserving variety between developers and users.
As an old software jobber, I have found myself thinking a lot about information flows between people in ways I really didn't before Dan's book. Even when I'm just trying to get somebody to agree on what to put on a pizza.
That's very interesting. I've seen shops that use train programmers as a source of potential traders, but never ones that train programmers on trading with the goal of making them better programmers.
>how many managers are aware of the research done into the relative effectiveness of programmers? They should be. The best are anything from ten to twenty times as good as the worst
This is a great point, although it runs converse to the main thesis.
Computers can do wonderful things if they have wonderful people running them.
I feel like modern management (at least here in the US) is allergic to the idea that some individual humans are really good at their jobs. They'd rather have replaceable human resources. I think a lot of the AI hype is to allow people to do complicated jobs without any specialized training or experience.
Interesting to see the "10x programmer" getting an outing that predates Fred Brook's classic Mythical Man Month too
It pretty much has to be allergic to the idea, since you can't operate an organisation at scale without working out how to make effective use of the non-superstar workers.
I suppose the question I would have for Beer is “Why do you suppose this has not happened in the past 50 years? Surely someone would write a computer program to run a small business that would be hyper efficient by standards of the day and proceed to take over the world. Why didn’t that happen?”
Now, I think the best rejoinder is “Amazon pretty much did”, but I note that it isn’t quite the way Beer is imagining things.
We might say Shein have done a lot of it too - although you might quite fairly reply also not quite the way Beer imagined things. I think one can also make the case that Toyota got quite far down the track he is describing - and I think this reveals one of the issues - really he is thinking of manufacturing.
LLMs might hold out the possibility of extending beyond manufacturing - but they might also not really be ready yet for it. (And possibly without further architectural innovation, not ever.)
Yea, you can get pretty far with manufacturing planning with computers, but even there actual optimization is a real bear to get going, as the data maintenance becomes monstrous and the question of how close your computer model actually cleaves to your physical process becomes a big problem. I've worked in supply chain and operations planning for nearly 20 years now implementing MRP systems, and almost always the correct answer is "don't try to do finite scheduling" unless you have a very sophisticated organization with a lot of people to stay on it. Arguably, it might require more humans to keep things going with the computer doing finite scheduling than letting humans do it for many firms. You absolutely could not have gotten there before the 2000's, and even today the mainstream ERP systems are not great at it, although many smaller firms offer better bolt on options.
Beer was writing in an era of mainframes and minicomputers. But since he survived to 2002, he saw computers become personal, portable, and with a vast quantity of interesting software that is light years from quantitative management information systems. The problem, if any, is resistance to change (like housebuilding designs) and a failure to visualize how business could change (resistance of managers). Interestingly, innovative software design remains marginalized for some reason, whether engineers are resistant to change, lack imagination, or their corporate bosses lack imagination.
What was Beer's great insight? The nested command and control system based on cybernetics. As the Chile experiment showed, he was really pushing for an automated, real Socialism that would have benefited the USSR command economy. Western countries steered well clear of that losing approach, and we can see the result. Yes, the problems you outline in your excellent book still exist, and just maybe cybernetics and better management structure designs could alleviate some of those problems, although the examples often refer to large corporations with deep management hierarchies - the same problems that large national democracies face with a central government that maintains overall control.
Did Beer ever reflect on his famous ideas and change his mind, especially as IT has so changed over his lifetime?
Totally tangential to the post topic - but I was interested by the reference to Leibniz's mathesis universalis. Did Beer study philosophy -- or at least history of ideas? Possibly it just comes through history of maths.
Coordination of IRS data and immigration court appointment status has made it more efficient to harass, detain, deport and assault one segment of America's workforce and intimidate others. I guess this matters - who writes the programs and what she plans to do with the data.
Werner Von Braun really wanted his rockets to go to Mars but he was OK with using them to bomb London. He was, however, not too keen to learn about the slave labor that built them.
Before they got real power, techies thought computers could be used for cute things like storing recipes, or playing Pac Man. Now that they have power, they think tech should be used to get more of it.
Did you watch the scene in "2001" where the proto-human realizes a bone can be used as a club to kill? That's about where we are.