1. Consistent Understanding
In a large organization, we can think of a small team as a microservice.
As early as 1967, Conway proposed the concept of the microservice. Conway argued that any organization designing a system will deliver a design whose structure is consistent with that organization’s communication structure.
When developing complex systems, we usually split the system into modules. On one hand, the difficulty of the problems an individual can solve is limited; on the other hand, individuals differ from one another to some degree. Hiring better engineers means greater cost. Splitting into modules effectively lowers the difficulty of the problems and saves cost.
Each module needs a certain number of engineers, and the engineers who gather together form a team. Such a team focuses only on the module it is responsible for, without having to consider anything else, so that the complexity of the problem converges.
Looking at the whole, the top-level architect decides how to divide the modules, and the existence of each sub-module determines the need for a smaller level of organization, and so on recursively. From the perspective of a small team, it can be autonomous internally, adjusting and optimizing freely, but externally it must remain stable. From the perspective of an individual, what he is responsible for is specific affairs, and these affairs aggregate together to keep the organization one level up running normally.
Only by understanding the organization and recognizing its responsibilities can our decisions have a unified standard. There is nothing controversial about this statement, and of course nothing valuable about it either. The key question is whether the members of an organization can keep a consistent understanding of the organization, and whether that understanding can stay closer to the organization one level up.
From the perspective of technology serving the business, it is necessary to strengthen the level of understanding of the organization among peers at the same level.
2. Consistent Toolchain
Within a team, unifying the development environment is not an easy thing; otherwise there would be no dispute between Vim and Emacs.
However, different operating systems, different editors, and different shared components all bring trouble to communication. A new intern arrives, projects intersect, the system is reinstalled, the computer is replaced… all of these require time to rebuild the development environment. Even if documentation is captured every time, it is hard to cover every scenario, and the documentation still needs to be updated and maintained.
Virtualization technologies such as Vagrant, Docker, and VirtualBox can be used to shield environment differences and build a unified development environment.
Recently, I also made an adjustment to my development environment. Previously, I had always set up the development environment locally on Windows, and I also tried Docker, but neither was very convenient. Windows needs to work with MINGW, and Docker needs to work with VirtualBox, but neither can simulate the online runtime environment.
Now, I develop on CentOS using a virtual machine. At the same time, I store the virtual machine in a cloud drive, sync it online, and sync it across the various development machines.
Going a step further, within a team the toolchain used should also be kept as consistent as possible.
