Mid-term Summary, Answers to 3 Typical Questions and How to Study Efficiently 1 #

Hello, I am Shi Xuefeng. Unknowingly, the column has been online for nearly two months, and overall progress is more than halfway there. At the beginning of writing this column, I set a small goal for myself: to take every comment seriously. Until now, just by replying to comments, I have already written more than 30,000 words.

Actually, for me, every time I read comments and reply to them is a process of constant reflection and learning. In fact, many times, many comments and discussions are even more exciting and down-to-earth than the articles themselves.

Today is the midterm summary, and I will talk about it in two parts:

• Part 1: I have selected 3 typical questions from numerous comments and explained them in detail.
• Part 2: I want to talk to you about some words from my heart. Two months of intense writing have also allowed me to reexamine “how to study efficiently” from the perspective of a lecturer. I am sharing these thoughts with you in the hope that they can help you improve yourself.

Typical Problems #

First, let’s look at some typical problems.

Problem 1 #

Agile development models do not spend a lot of time studying the business. Does this mean that if the business is not thoroughly analyzed, it can lead to deviation in direction, or even the discovery halfway through the system development that the overall business architecture is not reasonable, requiring rework?

As you may know, implementing DevOps helps in the rapid and high-quality delivery of products. However, I would like to ask: does rapid and high-quality delivery necessarily mean business success? Clearly, it is not that simple.

In fact, there are many factors that affect business success, such as industry trends, product competitiveness, user consumption habits, policies, laws and regulations, and so on. Among these factors, the quality of requirements, or more precisely, whether the requirements are reliable, is also crucial.

After all, delivering a bunch of useless requirements not only fails to improve the business but also wastes a lot of time and energy, missing out on truly valuable opportunities.

We are in a rapidly changing era, and businesses are not clear about what users really want. Many requirements are derived from subjective assumptions. When proposing a new requirement, how much value does it really bring? This is not only difficult to predict but also difficult to measure.

Therefore, product teams tend to use a “spray and pray” approach, proposing a bunch of requirements to increase the chances of hitting the mark. After all, if accuracy cannot be achieved in one attempt, try multiple times.

From this perspective, whether adopting agile development or waterfall development does not have a direct relationship with the reliability of requirements. Even in a waterfall model, “disaster through large efforts” cases still exist, such as Motorola’s Iridium project.

Since it is impossible to predict in advance whether the requirements are reliable, solving this problem requires close collaboration between the business team and the delivery team.

From the business side, it means adopting lean startup thinking, breaking down requirements through Minimum Viable Products, and reducing the market trial and error costs through prototyping. This brings up a series of techniques and methods mentioned in the lecture on “Business Agility”, such as Impact Maps, Kano Model, User Stories, etc., all aimed at obtaining market feedback through continuous iteration and small, quick steps. It is because of this that the agile development model, which embraces change more flexibly, is widely accepted.

After discussing the business side, let’s take a look at the delivery side.

After an idea is proposed, it needs to go through the software development and delivery process to finally reach the hands of users. Therefore, it is necessary to use all means to shorten the duration of this delivery pipeline.

If the development time cost is fixed, then the remaining parts are the problems that various engineering practices in DevOps try to solve.

For example, by using continuous integration to reduce the resolution cost in software integration, and reduce the cost of fixing software defects that are discovered at the last moment; by automating testing, reducing the cost of executing a large number of manual regression test cases, and reducing the cost of fixing existing functionalities due to new functionalities. Similarly, most other parts of the software delivery process follow this principle. This is also the reason why each field has its own set of practices. Looking at it the other way around, after the functionality goes online, it is still necessary for the delivery side to extract, summarize, and provide timely feedback on business metrics to prove the reliability of the requirements and help the business side make more orderly decisions. Timely stop loss for poorly performing features, and increased investment for features that reflect well.

In this way, the business side’s requirement decomposition and requirement analysis reduces the granularity of the requirements and improves the reliability of the requirements; the engineering practices of the delivery side greatly shorten the delivery cycle of the online system and improve the quality. This helps the business validate more requirements without increasing costs. The lower the cost and the higher the frequency of this process, the higher the chance of survival and overall competitiveness of the enterprise. This is also the core problem that DevOps wants to solve.

Question 2 #

The company doesn’t pay much attention to configuration management. Are there any good practical methods to build a complete configuration management system?

In Lecture 10 of the column, I started with 4 core principles to introduce the relevant knowledge of configuration management, which has resonated with many students.

Indeed, as a long-term neglected but particularly important practice, configuration management is not only the foundation of many DevOps engineering practices, but also the culmination of engineering capabilities.

Because of this, the establishment of a configuration management system is not just about doing a good job of configuration management. In fact, it depends on the joint implementation of other engineering practices.

As for how to implement configuration management, let me share a case with you.

This company initially did not have a dedicated configuration management role, and software integration and releases were managed by the development team themselves. The opportunity to establish a configuration management system came when the company decided to accelerate the pace of version releases, changing from one version every three weeks to one version every two weeks. It may seem like just shortening the release cycle by one week, but as I demonstrated in Lecture 4 of the column, achieving this goal requires efforts in all aspects, including configuration management.

So, the company decided to introduce a configuration management position. In the initial stage, they focused on two things:

• Redefining branch strategies, changing from long-term branches to a short-term branch with feature branches model;
• Managing integration permissions, changing from being able to integrate code at any time to controlling integration based on version cycles.

In this process, the configuration management team sorted out the directory structure and storage method of the code repository, and based on the development process, established an online platform for testing submissions, thus realizing the online process of development and automated management of permissions.

Next, configuration management combined with the platform and processes to extend the development process forward and backward.

• Forward : In the requirement management stage, establish standards for the association of requirements and code, strictly control code submission checks, and incorporate build tools and environment configurations into unified control for traceable historical changes.
• Backward : In the deployment and operation phase, define version release and deployment rules, establish a single trusted release channel, and enable unified access to information about all official release versions, including requirement information, code information, and test information associated with the version.

After the team got on track with orderly development, they gradually strengthened the construction of the platform and automation capabilities to address the discovered issues.

• Uncontrolled code submissions: Implement online integration, automatically merge code after passing tests and acceptance;
• Significant environment differences: Achieve unified initialization through containerization and server configuration management tools;
• Slow build speed: Improve build speed through network optimization and incremental compilation.

As a result, version releases, which used to be time-consuming and labor-intensive operations, have become one-click operations, and the team has achieved the goal of bi-weekly releases as expected.

Throughout this case, configuration management focused more on processes and platforms. By establishing rules, controlling permissions, unifying information sources, and using version control mechanisms, the entire development collaboration and delivery process has been reshaped.

Therefore, when facing various practices and trying to determine which ones can solve practical problems, it is best to work backwards from the expected results.

If you don’t know where to start, you can check if the current software delivery process is driven by configuration management, if there are any data that are out of control and in a chaotic state, and if the information about versions cannot be completely traced. If any of these apply, then there are many opportunities for improvement.

In conclusion, any company that wants to implement configuration management can start with standardization, then move on to automation, and finally to dataization and serviceization. This is a relatively universal path and a general guide for implementing configuration management.

Question 3 #

How should metrics be associated with organizations and individuals? With so many metrics, how can they be linked to projects effectively?

In Lesson 19, I introduced the practice of positive metrics, which caused quite a stir. After the article was published, many students added me as a friend and had in-depth discussions and exchanges with me about metric construction. This shows that currently, measuring development in enterprises is a hot topic.

However, metrics are an endless abyss, the more you do, the more you realize it. So, in the very beginning, are there any reference steps that can guide practice? Of course, there are. I summarized four steps: find a starting point, examine the big numbers, detect gaps, and categorize.

Step 1: Find a starting point.

For the construction of a metrics system, many companies are actually quite similar. Initially, the core requirement is to have a starting point to organize the entire development process. This starting point is often the requirements because requirements are the thread that runs through the entire development and delivery process.

Of course, you can also consider if there are other options besides requirements. So, around the core metrics related to requirements, the first thing to extract is the content. If you don’t even have the lead time of a requirement across different stages of the delivery cycle, then the metric is not qualified.

Step 2: Examine the big numbers.

Examining the big numbers means that after the metric system extracts and calculates the metric data according to its definition, the most important thing is to verify the authenticity and validity of the data and make the team acknowledge these objective data.

Many times, if there is no authoritative set of metrics within the company, different departments and systems will have their metrics standards. If this discussion is conducted without consensus, it is basically meaningless. Therefore, it is essential to make the team recognize the rationality of these big numbers.

Step 3: Detect gaps.

Once you have the starting point and the core metrics, and everyone agrees on the objectivity and validity of the metric data, there will still be obvious areas that are not reasonable at this stage. At this point, you need to further break down these areas. For example, the test cycle may be just a number in the larger stages, but in reality, it includes many processes such as functional testing, product inspection, and data testing.

If you don’t break down the surface problems into the actual situations of each step, it will be difficult to explain which step is causing the problem. Therefore, under the premise of reaching a consensus, identify the areas that can be improved. This is a milestone victory.

Step 4: Categorize.

In reality, not all metrics can be associated with individuals. For example, does it feel strange to calculate an individual’s requirement lead time? Similarly, it is challenging to associate metrics such as application crash rates with a specific department.

So, we need to categorize the metrics based on different perspectives and dimensions. For example, we can categorize them into organizational-level, team-level, and project-level metrics.

The key to categorizing metrics is still to break them down from large to small, starting from the audience of the metrics and the problems they are trying to solve, and gradually reaching the root causes of the problems, such as user operation reasons, data calculation reasons, automation platform reasons, and so on. Of course, this is a very meticulous task.

Now let’s review the three typical DevOps problems that we just analyzed in depth.

First, you need to know very clearly that when facing unknown requirements, the solution and method for DevOps is to analyze reliable requirements on the business side and complete delivery on the delivery side as quickly and with as low cost as possible. They are a community with shared destiny, they rise and fall together.

As a core fundamental practice of DevOps, configuration management is not limited to a single area during implementation. In fact, it should be driven by the optimization of the development process, leading to the construction of standardization, automation, and data visualization capabilities.

Finally, regarding metrics, the key thing to note is that upwards, they should support core metrics; downwards, they should be broken down layer by layer to show the real details.

After discussing these three typical problems, we will now move on to Part 2, which is also a part I strongly requested to add. I just want to talk to you from the bottom of my heart.

How to Study Efficiently? #

Like you, I am also a user of GeekTime and have subscribed to many interesting courses. During the process of studying, I have been pondering how to study efficiently within limited time. It wasn’t until I became a course instructor myself that I started thinking about this question from the perspectives of both a user and a teacher. I have gained some insights and would like to share them with you.

Being busy is a true reflection of most people’s lives nowadays. From morning till night, we are busy with work, meetings, and constantly checking our phones… We are overwhelmingly busy.

However, if you were asked what you were busy with the previous day, either your mind goes blank or you can only remember a random list of things. It’s clear that many of the things we are busy with every day hold little value.

In fact, many things are not as important as we imagine them to be. We often focus our attention on the present, making it seem like the whole world revolves around what is happening right now. However, if we extend the timeframe to a week or even a year, you will realize that these things make no significant difference whether they are done or not.

Because we are constantly in a state of busyness, setting aside a dedicated block of time for studying becomes a luxury. But I congratulate you, because at least you are more conscious and aware than most people. You are willing to set aside fragments of time to enrich yourself.

Since you have spent this precious time, you certainly hope to gain something from it, whether it’s knowledge, skills, or broadening your perspective. At the very least, you don’t want to waste this time in vain.

So, I want to ask you, did you really gain anything?

Stephen Covey once said, “Most of people listen with the intent to reply, but not with the intent to understand.”

In this context, “reply” is a bit exaggerated. But in reality, I have found that when I’m communicating, I often unconsciously think about how to respond to the other person, rather than truly listening to their words and understanding their intentions and emotions.

As you can see, this listening mode of learning is always influenced by our inherent thinking patterns. In many cases, we tend to put ourselves in the role of a commenter.

So, what does it mean to be a commenter? It means taking a position of detachment, looking at things from a critical perspective, and trying to find problems. Of course, these problems are all discovered within our existing cognitive limitations.

This feedback is actually a good thing for knowledge producers because it allows them to constantly examine and reflect on themselves, and find areas for improvement.

However, for learners, can we temporarily give up the role of a commenter and instead become practitioners in the process of learning?

For example, taking GeekTime’s articles as an example, what different perspectives do you have on the content mentioned by the author? Faced with the same problems, what better methods do you have?

In fact, every author has their unique qualities that make them authors. So, being able to make use of their thoughts, complement your own knowledge with theirs, and become a winner in communication is a better choice that truly values your time.

Lastly, using GeekTime’s articles as an example, I believe:

• A 60-point experience means being able to read through all the articles, not just listening to the audio of the course.
• A 70-point experience means carefully studying the additional resources in the articles, such as code, flowcharts, and supplementary learning information, which are selected materials to help expand your knowledge beyond the 15-minute block.
• An 80-point experience means actively participating in the comments and discussions of the articles, and even engaging in deep conversations with the author about your own questions, establishing connections.
• A 90-point experience means combining real-life scenarios from work, giving your own thoughts and answers, accumulating your own knowledge system, and being able to share it with others.
• A 100-point experience means continuous improvement. I believe that having this mindset may be more important than achieving a perfect score itself.

So, how many points of experience do you want to achieve? Take some time to think about it yourself.

Alright, next, we will soon enter the “Tool and Practicality” section. I hope you can continue to maintain your passion for learning, persevere, and look forward to good things happening naturally.

Thought Questions #

Do you have any points of confusion regarding the content that has been covered so far? Or, do you have any questions that have come up during your practice?

Please feel free to share your thoughts and answers in the comments section. Let’s discuss and learn together to make progress. If you find this article helpful, please also consider sharing it with your friends.