After ten years in the automotive industry I can confirm that some observations from the article also happens there: If you look at the system architecture (par

After ten years in the automotive industry I can confirm that some observations from the article also happens there: If you look at the system architecture (parts, components, connections) of a car you can also very certainly identify the companies organizational structure. You would also see there that the architecture is optimized for solving the problem with least amount of effort and redundancy. But nevertheless, working in such a gigantic environment I also concluded that this still makes sense. You simply need a well defined boundary up to which you and your team are responsible and a well defined interface against which your are developing. In the electrical engineering world these are often interfaces described in form of messages that are defined on classical bus systems (e.g. CAN), which worked quite decent. I worked a lot on the introduction of IP networking based interfaces, which (besides allowing other network layers and higher speeds) also can be used for describing interfaces between different software parts which might still be deployed in the same hardware. This yielded the advantages that Joe Armstrong described here: Different parties can work very independently, using different technologies and you can compose the results to a complete system. However I can't say that I would use the approach for everything, because I comes with a certain overhead - in performance as well as in the development process. E.g. to have a large number of developers (could easily be > 100) the same understanding of an interface and develop against it you really need a perfect static definition of the interface, for at least some parts a dynamic description (state and sequence charts) and test tools that work against both sides. The interface definition must be maintained by someone (probably neither the groups that implement the server or the client side) and changes will be much much slower than a change somewhere in a monolithic codebase (can be month from the change of an interface description until all sides have adapted the new version). I would also heavily recomment the use of some interface definition language (anything from custom, protobuf, thrift, swagger, etc.) and the use of a framework and code generations tools and client and server side. Manually processing JSON or even worse writing bytes manually to a socket won't work at scale.