Martin Fowler says no!

So what? We can use the following process indicators to guide daily improvement:

The meeting time

If Autonomy’s problem was high communication costs, is it possible to directly measure the overall cost of communication? Time spent in meetings, for example, is a possible indicator. What could be wrong with such indicators? Is there a better indicator?

Measuring meeting time has the following problems:

  • Meetings do not cover the full cost of communication, including face-to-face communication, IM communication, etc
  • The meeting may not be held because there are no new requirements
  • More meetings may be because there is more demand, indicating that business is booming
  • Are meetings more or less about cost, as long as the ultimate efficiency is OK? Or in other words, as long as the business makes money, isn’t that OK?

The most effective outcome measures are, of course, total revenue and total profit. But it does not follow that all process indicators are meaningless. It is impossible for everyone to memorize the end result metrics, and it is impossible for all improvement to start with the end result metrics. Meeting time clearly tells the story of the cost, but whether it was worth it is hard to tell. A laborer has only 8 hours of labor law working hours, if there are 7 hours in the meeting, apparently can explain some problems. So I think meeting time is of some significance as an observational process indicator. The main function is to draw a red line, beyond which there are too many meetings.

The problem with meeting time is that it is not a guide to improvement. Because there are more meetings, there may simply be more demand.

Interface Change/Implement Change ratio

We divide files into two types, those responsible for interfaces and those responsible for implementation. Ideally, interfaces should be changed as little as possible, and implementations should be changed primarily to reduce cross-module human communication. If a new requirement, N modules need to be changed at the same time. But as long as you don’t need to change the interface (including implicit interfaces in the form of Map

), this is still ideal. While product managers need to communicate with multiple teams what the requirements for each part are, there can still be little communication between development teams. It is not realistic for a team to be responsible for changing only one module for each new requirement:
,>

  • New business practices are often disruptive. Let’s not try to predict ahead of time
  • The size of the requirements is arbitrary, and the division of product managers is random. There is always a way to make a need so big that the whole company only does one need.

It is impossible for interfaces to be completely unmodified and for developers to communicate with each other. What we need to focus on is whether the current split of business logic is reasonable, and if the interfaces between Git repositories need to be adjusted frequently, then the Git repository is too fragmented, or the boundaries are not optimal. Keep reviewing past split decisions in light of new inputs. The “interface change”/” implementation change “ratio quantifies whether the current business logic split has Autonomy for each Git repository. The smaller this value is, the higher the proportion of changes only to the implementation.

In order to make the data more stable:

  • Only file level differences are made. A file either belongs to an interface or an implementation. Such isolation can generally be achieved through technical means.
  • No matter how many changes are made and how many files are changed in a day, it is counted as “1 change”. This avoids data fluctuations caused by multiple submissions or the number of documents.

In extreme cases, we can have no Git repositories, or just two, to make the interface change/implement change ratio look better. This also illustrates the cost of splitting Git repositories. The more fragmented the business logic, the more cross-team communication will inevitably increase. Git repositories are not as divided as possible, but as divided as possible.

Another problem with this metric is that regular copy changes can lead to a lot of implementation changes. So we have to balance with the “Consistency” dimension. Suppose we already have a unified copy configuration mechanism. Then there needs to be an indicator of the access rate of the copywriting configuration mechanism. In this way, daily routine changes can avoid undermining the authenticity of this indicator.

One of the most important ideas in A Philosophy of Software Design is “Modules should be deep”, A metaphor that focuses attention on static structures. If the interface is much smaller than the implementation, the probability that the interface will be modified is much smaller than the implementation. That way we can change the implementation, not the interface, most of the time. The costs and benefits of “business logic splitting” are reflected in the subsequent creation of new requirements, taking away the timeline of business change and not being measured by a static code structure.

Access rate

It is not considered a meaningful metric to identify “code repetition rate”. Code duplication is not necessarily a problem. It’s hard to say that code is the same today and will be the same tomorrow. However “reuse” can lead to coupling and reduce team Autonomy. A classic example of this is the utils package, the utils class. No one can say when to use the utils class you extracted, or when not to use it. If reusable code is pulled out, the starting point should be consistency, a conscious act after key team members have reached agreement.

For every Git repository that is reusable, you need to define your scope. Access rates need to be measured within the scope of application. If you don’t know what to reuse and what not to reuse, treat it as one-time business logic and don’t let other Git repositories rely on it. The access rate is automatically calculated based on code scanning. The access rate can be calculated by pattern match. The access rate can be directly calculated by referring to code symbols.

Blocking rate

When we use a programming language like Java, Java prevents you from manipulating the CPU directly in assembly language in your code. This is typical of “blocking”. Blocking is also used to ensure consistency.

If you’re using a programming language like C++, chances are there’s no consensus among Git repositories about what a string is. Within a certain scope (for example, a project, a department), it must be mandatory for all Git repositories to access the same String library to ensure low friction for interoperability.

Similarly, a distributed application with RPC calls to each other, each process using different RPC protocols, and using different RPC implementation libraries to communicate with each other can cause many problems. For example, if A calls B and C again, and the call fails, the layer upon layer of retries may result in the lowest level module being repeatedly tried and finally destroyed. The solution is to require all processes on the distributed call chain to follow the same retry rules. If there is no way to “block” the implementation of masturbation RPC, see an HTTP URL, directly find a random HTTP library to call, then it is difficult to guarantee the consistency of retry rules.

The blocking rate refers to how many of the accessible places are subjected to mandatory checks to ensure that violations are blocked.

inquiries

When a team is positioned as a “reusable module”, it is lonely. It is a great honor to be invited to participate in the Feature Team of a key project. However, to ensure Consistency, reusable Git repositories should strive to reduce user costs. The biggest cost to users comes from communication inquiries. If the documentation is not clear, the access method is manual, which will inevitably be reflected in the volume of inquiries.

How to calculate this index of consultation volume is difficult to make clear. In different teams, the amount of consulting is represented in different ways. So the closer you get to zero, the better.

Time of work order transfer

Work orders created by external users of the enterprise will be transferred to the corresponding developer if they are found to need development for disposal. The time difference between the creation time of work order and the beginning of development is the work order flow delay. This metric is mainly measured to avoid back-end modules lacking empathy for the enterprise end-user experience and reducing the intermediate layers. Here work order refers to the occasional case. For the work order caused by a large fault, the work order within one day is merged into one record. That is, when data sampling, only one work order is extracted for inclusion in the index.

Fault Location duration

It is difficult for an isolated process to do all the work. Business logic is inevitably split into multiple processes. How to find the process that is failing. It’s also hard to build a process from just one Git repository. Business logic is inevitably split into Git repositories. How to find out which Git repository is responsible for the process problem. Fault location delay refers to the time between fault location and root cause. Process boundaries, Git repository boundaries, are less dependent on human experience, and less dependent on human field communication, the more likely it is to reduce fault location delays.

Code integration duration

From modifying a line of code to integrating that change with other processes, verify with real traffic what the end-to-end delay is. One way to do this is to develop your own laptop that can boot up all the processes. Development can also use unit tests to simulate trials. Going online every hour is another option. As long as you can be confident that the line of code that you just changed will integrate without a problem. So we didn’t use “local development environment setup time” as a metric, because being able to start processes locally was the means, and integration testing was the actual end.

Business logic split mode

The above are the possible useful indicators sorted out by us, taowen/ modullasing-examples in the whole article

Fly book group: go.feishu.cn/JWfUAr3/