"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
When the organization structure of a project is 'there's just one guy who does it all', the software architecture will tend towards 'the big ball of code' pattern.
However, if the team on a project has people who are engineers, and people who are designers, then a designineer might be a useful product manager to help balance conflicting engineering and UX requirements.
In a startup, looking for a first hire engineer, you probably want someone who will grow into that role - but it's a mistake to have your first system built by them and them alone, because you'll almost inevitably wind up with a big ball of code.
In general, all software should be built by at least two people collaborating, to force some division of responsibility, which will (via Conway's Law) force some structure.
(as you say, the best developers are disciplined and capable of structuring systems in the absence of a forcing structure. This is maybe because they divide work logically into units, and therefore find themselves collaborating with their past- and future-self, giving the structural effect of team work. But apply pressure to even a great developer and that discipline can break down.)
I don't know if I agree with this. It seems like the more people there are working on a project, the more likely you will end up with a complicated ball of code. The reason being is people generally aren't working with the same mental model on the system they are implementing. So, some of the engineers will think its obvious to do things one way, and others will do the opposite. It doesn't make sense for complete rewrites when the other engineer reviews the code, so you end up with inconsistencies in the code. At that point there is no real way to look at the code in a coherent fashion. It doesn't completely make sense to the first or second engineer. It has become a complicated ball of code.
If we accept the initial premise that designers who are also engineers are as rare as ninja-unicorns, then surely the logical thing to do is to turn them into managers?
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
When the organization structure of a project is 'there's just one guy who does it all', the software architecture will tend towards 'the big ball of code' pattern.
However, if the team on a project has people who are engineers, and people who are designers, then a designineer might be a useful product manager to help balance conflicting engineering and UX requirements.
In a startup, looking for a first hire engineer, you probably want someone who will grow into that role - but it's a mistake to have your first system built by them and them alone, because you'll almost inevitably wind up with a big ball of code.
In general, all software should be built by at least two people collaborating, to force some division of responsibility, which will (via Conway's Law) force some structure.
(as you say, the best developers are disciplined and capable of structuring systems in the absence of a forcing structure. This is maybe because they divide work logically into units, and therefore find themselves collaborating with their past- and future-self, giving the structural effect of team work. But apply pressure to even a great developer and that discipline can break down.)