[Agile best practices] From poker to software development

I have always believed that software development is like a collaborative game.Jay fields masterpieceSoftware development lessons learned from pokerThen, I am more convinced of this point! We recommend it to you !!

---------------------------------------------------------------------

I used to do not develop software. Two years before I joined thoughtworks, I made a living mainly by playing poker. Of course, if you have asked me about the tattoos on my forearm, you must have heard of my story. If not, I can tell you the next time we have a drink together.

I have never felt sorry for spending so much time playing cards, and I have learned a wide range of knowledge. The longer it takes to develop software, the more I believe that the two have incredible similarities.

Learning

I learned to play poker and to develop software in the same way: read as much as possible. I spent two years reading every book I could find about poker. Finally, as many as 39. Programming is also true. At this moment, I still see the five books to be read next. In the past three years, thoughtworks has not seen a few of my rotten books.

In my opinion, reading books, blogs, and magazines, whether programming or playing cards, is a prerequisite for achieving something. If you want to take the two for a living, it is far from enough to rely on reading only. Maybe you can put all the knowledge in books into your mind, but knowing when to apply the rules is a sign of true masters.

It is true that it is helpful to open a volume. However, it is always a great journey to get familiar with the specific environment of specific technologies. Books cannot cover all the situations. Only the experience you have gained can you make quick and correct decisions for yourself or your employer in some situations, these decisions may be worth thousands or even millions of dollars.

The value of experience is nothing in the world.

The peak of Art

You can design a computer program to beat normal poker players. By following some basic rules, you can naturally win. But so far, no program can beat the best poker players. Because poker becomes an art when it reaches its peak. This is also true for software development. To become a good developer, you only need to follow a series of best practices. If you follow books such as the classic reference guide, developing good applications should not be a problem, and the results will be better than other common practices. With so many failed projects as an example, I believe that a good application is enough to make most of the management willing to pay for it.

Of course, some managers have higher standards. In banking, startups, medical systems, and other fields, standards are more stringent. "Not bad" is far from enough. Those managers will be happy to pay for the best choice, and they expect far more skills than ordinary people. However, the problem is that expert programmers have different skills than ordinary programmers. Ordinary programmers know how to do things, and experts know the purpose of doing things. Ordinary programmers will follow the instructions in the Model Book, just as they follow the Reference Guide. Experts will understand that model innovation may bring exponential performance improvements.

What they see is not the same world, so it is difficult for common programmers to communicate with experts. It is easy to be an art critic and hard to be an excellent art critic.

Decision-making skills

There is an absolute truth in poker and programming: almost no one can feel as good as himself. It is a good start to be self-aware, but it is still difficult for people to know the gap between themselves and experts. Programmers do not have many opportunities to access experts, so they cannot judge their skills fairly. On the card table, everyone is here for the sake of success, but most people will think too much about their skills, which is always surprising to me.

This is also true for programmers, and most people have less information. A technical leader who never participates in any conference can only compete with his team members. Of course, he may already be excellent, or he will not become a technical leader. But what is the position of the most outstanding person in the industry? If I think that my circle is already full of views, what will he do when I come across different opinions? Some people will regard it as an opportunity to learn and are excited, but most people will sneer at different opinions.

Team collaboration

At first glance, poker is a game of mutual confrontation. But this is rare. Even on the cards with the smallest bet, there are usually at least a few people dealing with it. They won't reach a condition to deal with the rest of the cards-and they don't have. Everyone understands the truth: You don't want to compete with good players, win their money, but make money from low-level people. Professional players even work together like a team. Some people are related to each other's interests, so if one person gains profit, all people will gain benefits. They not only know each other, but also know many people. If there is a good game board, the floor manager will greet them; the waiter will prepare high-alcohol drinks for their opponents; and the hand (that is, the poster) it will intentionally "Make Mistakes" to influence the mood of a person (few people can play cards when they are in bad mood ). Everyone is working together to ensure that everyone can make money.

Interestingly, the programmer's situation is also similar. Many people sit in the lattice and rely entirely on themselves to solve the problem. They often work in a code-specific mode. I have witnessed with my own eyes that the integration problem has always been a heart disease in such applications delivered by programmers. Unfortunately, the pain point of integration is the smallest problem. Assume that the IT department locks the business requirements to the Requirement documents on 500 pages. If the company decides to change its business direction, the subsequent demand for system changes will be painful. Millions of dollars have been spent, because the features developed by programmers no longer have business value, and the IT department has not yet found a better way to cope with business changes.

Of course, this is not always the case. Experts know how to collaborate. They work with other experts, but do not reject collaboration with managers, customers, business departments, analysts, Quality Assurance personnel, and all those who can contribute to success. They have a big picture: Only collaboration can make everyone gain something.

Measurement

Ambitious players often discuss how many players they win and how many others they lose. The cards that were supposed to win but lost were the most discussed. Sometimes people make mistakes to lose money, but they generally do not remember how they lost these hands. On the contrary, if some cards are lost only because of their bad luck, they will remember every detail in the game and will reveal in the story their opponent's chance to win, to prove that you have no chance to win. Real players know how many cards they have lost and the approximate probability of failure. They know how to measure. Moreover, professional players focus on important metrics. It doesn't matter how many wins and how many wins you lose. What matters is how much you win and how much you lose. And, for your shit (Translator's note: Bad beat, that is, the loser at the start is better than the winner card, and the chance of winning is greater, but the winner has a better card at the key moment. Take a bad beat to describe the loser and lay a bad beat to describe the winner. Suffering is actually a headache for your opponent's card. Since your income comes from your opponent's mistake, you are complaining about why your opponent has given you money.

It is good to have measurement standards, but professionals know which standards are important, which are only distracting, and which are between them.

Software development also has many measurement standards, and the halo of many standards is far beyond their scope. For example, knowing the number of lines of code can hardly bring any value. Complex applications require a lot of code, but what is "equivalent? It depends on languages, tools, and other factors.

The number of bugs fixed is also an interesting topic, but slightly inferior to the previous one. Why do people care about how many bugs have been fixed? The number of bugs may have some value, but the number of bugs fixed does not bring us much useful information.

The feature completion rate is my favorite standard. Unless we use features to evaluate the workload, how many features do we know? Moreover, if the workload has been evaluated, why not compare the remaining work with the completed work to get the work progress? It is hard for me to see the value in the feature completion rate.

Code coverage reminds me of logging shit. This measurement is meaningful, but many people do not focus on it. Low code coverage means that there may be problems, but high code coverage only means that you have a large value of code coverage. There is no essential link between high code coverage and high quality.

Pay attention to people, not logic

If you have watched a video with a card, you probably have heard the following sentence: you are not playing with poker, but with people. This statement is extremely true. A player is undoubtedly a psychologist. Sometimes you really need some cards, but a good player is only part of the money. Once you have a good card, you need to know how to make good use of them. Should you add a card first, give a card first, give a card thoroughly, or follow up? These practices depend on many factors, but the key is to understand the opponent on the card table. When you get a good card, the primary goal is to win as much money as possible from your opponent, and the only way to achieve this is to find a way for your opponent to give you more money. Understanding the logic can help you win a few cards, and understanding people can help you win money.

People are equally important when delivering software. If software only makes everything work, it is much easier to turn it into an automated job. However, software is far from a simple combination of functions. During a golf competition, people sell software packages. When the family travels to Disney for free, they sign software service contracts. To avoid legal disputes, people will fulfill their contracts to build useless software. to surpass competitors, people will use software to speed up business response.

People use software, develop software, maintain software, or depend on software to some extent. Software development is closely related to the world. What is the difference between making variables into simple equations and producing high-quality software? However, software developers need to consider all the known and unknown variables introduced by each person to make guesses as far as they can. Knowing what should be done will benefit you, and knowing what must be done brings about the value is hard to measure. Understanding the logic can help you deliver applications, and understanding people can help you deliver value.

Work under Incomplete Information

At this point, the people who started playing cards handled the cards very well: they played every card and bet on it honestly. They never gave up the cards. This is what new users should do, unless you have a lot of money to spend. The difficulty lies in how to improve the level of beginners. There is a lot of information, and you need to pay attention to every detail on the card table: how they communicate, what have you dealt with each of them before, and how they play cards, who is winning, who is losing, and all these are different. Moreover, you cannot know what the opponent is and what the next card is. Your information has exceeded the limit you can handle, and far from all.

Programming is also true. Domain experts do not know anything, but it is meaningless to give everything to you. Besides, you do not need all domain knowledge. You need to be familiar with the team, but your colleagues always have something you can never know or fully understand. However, programmers can integrate necessary domain knowledge, Master team dynamics, and always provide technical insights. They know that they will never be part of Bai Xiaosheng. They know what is worth thinking and what should be ignored. Even if the surging information is still incomplete, they can always make the right decisions.

Instant feedback

Regular players play the best in games with few feedbacks. Because players win money based on information. Among the five cards, there is only one chance to make a bet. Each player has only one chance to analyze your information, and you have only one chance to make a mistake. Expert players prefer multiple rounds of games. The more the number of rounds in the game, the more chance they will have to benefit from low-level opponents. They like instant feedback and make adjustments based on feedback. In games with multiple rounds, each round can be fed back, so professional players can adjust their playing style based on the current situation.

Programmers also like instant feedback. The instant feedback from business personnel can help you avoid detours when building business applications. From the feedback from another programmer, a bug can be found before the software is productized. The continuous integration server can provide real-time integration feedback to avoid integration pain points. People who like agility can immediately say that iteration is a very effective practice, because it can give real-time feedback to programmers and business personnel. However, as a programmer, even if he doesn't like agility, he can realize the value of instant feedback. Even in a non-agile environment, he will strive for more feedback, this avoids wasting time and energy. Real-time feedback can help you understand whether the direction is correct or not, and every expert will cherish this information.

The context is king.

No choice is absolutely correct or absolutely wrong in poker or programming. If you have a pair of K, do you need to stop playing the game before turning the cards? Maybe. It depends on whether you are playing the game or gambling, whether you have reached the upper limit or no upper limit, where you are sitting, whether you have not followed the competition, or whether you have reached the upper limit. One thing I learned in poker is that all factors must be taken into account before giving an answer.

The longer I spent in programming, the deeper I feel. Java is a good choice sometimes, but it is not omnipotent. This applies to all programming languages. Tool. Hibernate is good, but ibatis is not applicable. When ibatis is not applicable, it will appear or create new solutions. Almost no solution is absolutely effective, and it plays its due role only in an appropriate situation. In the wrong environment, it may become a poison.

Therefore, in the face of a new language or tool, whether it is your intention to abandon your performance or put it bluntly, you may wish to first think about its applicable environment, try your best to suit the right of the case, and make your decisions.

View Original English text:Software development lessons learned from poker

AuthorJay FieldsTranslatorLi JianyuWww.infoq.com/cn/articles/fields-it-depends