Engineer Happiness Matters

Six months ago, I attended Worldwide Software Architecture Summit (WSAS'22), where many sessions were discussing complexity, especially the complexity of microservices. At that time, I wrote two insights as follows.

• Original Sin of Microservices, Part 1
• Original Sin of Microservices, Part 2

The main point is building a microservice architecture is not always the best solution, the complexity of microservice architecture is very high and there are many trade-offs, how to find a relatively good option among many choices is a challenge.

Recently, WSAS'22 was held for the second half of the year, and I also attended.

Among those sessions, Conway's Law was mentioned several times.

In order to maintain the microservice architecture, the organization structure also needs to be adjusted to properly maintain many services. In the reorganization, how to let engineers do their work more efficiently also became an important issue.

During the three-day session, I came to one conclusion.

The productivity of engineers can only be increased by focusing on the happiness of engineers.

How to do that? Well, it's not that hard.

1. Optimize the onboarding process. Let new engineers get into work mode faster.
2. Be able to local development. Although the software architecture is moving towards microservices, engineers need to be able to build a development environment with the equipment at hand.
3. Establish software testing, whether it is unit testing, integration testing or even continuous integration, having a good testing framework to find defects as early as possible will make people more motivated.
4. Reduce the cognitive load. This covers a wide range of topics, including complete documentation to guide engineers, service templates to reduce the initial process of developing a new service, and a good continuous deployment process to reduce the background knowledge on operations.
5. Have the permission to do whatever needs to be done, otherwise it will be stuck in various approval processes.

These five items are more from the engineer's point of view and I believe they are easy to understand.

If you can focus on what needs to be done and have a good way to get it done, then the engineer should be happy.

But there is another item I feel is the most important.

Improving the code quality.

I believe we can all agree poor code can have a serious impact on productivity, but how much? Is there any way to measure it?

One session is a static scanning company, they published a paper, which mentioned that

1. 15 times more bugs in poor code than good code.
2. the development speed of poor code is 2 times slower than good code.
3. the feature delivery time of poor code is 9 times longer than that of good code.

From these supporting evidence, it is also indirectly proven that if an engineer has to suffer from poor code, he will not be happy.

From my point of view, microservice governance is much more important than microservice architecture. As an architect, I put more emphasis on how to practice than the perfect architecture. An architecture that makes engineers happy is a good architecture, whether it's a monolith or a microservice.