Chinese Idiom Stories for Software Professionals: #1 Seven-Step Poem (七步詩)

On Nov 2, 2021, Elon Musk tweeted with a Chinese poem, in literally Chinese characters.

This is the translation on Wikipedia.

Beanstalks are ignited to boil beans, In the pot, the beans weep. [We are] born of the selfsame root, Why in such a rush to fry me!

The tweet made global news. There were plenty of analysing articles on Elon Musk's intention behind the tweet, such as ‘climate change’ and ‘tension between Taiwan and mainland China”. A humorous one: "Elon is posting a bean recipe".

Why am I writing this?

My daughter is about to start her first IT job (internship) in a few weeks’ time. Though programming and testing is largely objective, 0 or 1, software development is a human activity. Therefore, it will have all highs and lows when working with other people. Here I want to share with her my over 20 years of experience in a fun way.

A few years ago, a thought came to me: “use Chinese idioms to explain some of the problems I have witnessed in the software industry (in particular, test automation and continuous testing) ”. Human nature has changed little, and these Chinese idioms stand the test of time (over 1000 years).

While I wrote these for my daughter, I will make them publicly available.

Frankly, my preparation is not fully ready yet. However, I got encouraged by Elon Musk’s tweet. I have to start from somewhere. Why not from here now?

Why use Chinese idioms (in English)?

I only know two languages well: Chinese and English. 😊

• Chinese idioms are insightful

For example, "The Art of War" (孫子兵法), a thin book written in 2,500 years ago, is a best-seller book in western countries and is especially liked by business people.

I tried to teach my daughter (born in Australia) Chinese based on textbooks, with no good results. Just like many kids, she showed little interest in learning a second language. Then I changed my approach by telling her Chinese idiom stories as her bedtime stories, and she liked them. Now she is comfortable with speaking, and reading and OK with writing in Chinese, and passed HSK — Level 5 (the qualification to attend Chinese universities) at a near-perfect score.

• Chinese idioms are concise

In every language/culture, a short proverb can convey a lot more information. For example, when you are in an unfamiliar situation and try to behave like the people who are already there, you would say: When in Rome, do as the Romans do. Compared to most of the proverbs from other countries, one particular attribute of Chinese idioms is that they are concise as most of them use only four Chinese characters.

Story: Seven-Step Poem

After Cao Cao (a famous warlord in Chinese history) died in 220, his eldest son Pi inherited the throne. Pi considered his younger brother Zhi a threat to his power. The reason: Zhi was known for his intelligence.

Pi accused Zhi's reputation was fake. Pi came up with a test for Zhi: writing a poem within seven steps of walking and the topic of the poem must be related to the current situation. The failure of this test would cost Zhi’s life, just like in the “Squid Games” TV show.

Zhi, a true genius, passed the test with this famous poem. And he lived.

For Software Professionals

What advice can a software professional take from this story (supposed to be real)? I can think of two:

1. Use practical tests for job candidates

15 years ago, there were no job titles such as "Agile Coach", "ScrumMaster", "Software Engineer in Test", or "DevOps Engineer". Yet, there were software projects delivered with high quality (functionally and infrastructure).

Back then, we had RAD (iterative development) and eXtreme Programming (XP, a truly agile methodology), and software teams did testing and deployment. These days, what do people with new job titles bring to your project? Not much. In fact, often I found they made things complicated, and worse.

Consider these questions:

• Does your team push updates to production after every sprint?
• How does your team conduct functional testing? Is it done manually?
• Does your so-called CI/CD process run comprehensive E2E tests?
• Do you deploy apps (to test and production envs) frequently and reliably?\

Those fake coaches/engineers often used all sorts of excuses, such as "this software architecture is different from my last one". WRONG! For all these roles, the knowledge and practices are almost 100% transferable. I verified this with many projects over 20 years. For example, if it is a web app, I used the same test automation formula and created at least a key automated test on the first day. Most of the time, I set up a Continuous Testing server (this has some dependency on infrastructure) on the same day as well.

A wise IT executive should learn from King Pi in this story. Despite his evil intent, he proved his brother’s talents. Test your candidates with some practical yet simple practices, without punishment, of course, ☺. People who have real skills, like Zhi, will not fear simple and practical tests.

Timeboxing is a concept in agile methodology.

“Timebox as a fixed period of time, at the end of which an objective has been met”

An important factor is time. Pi gave Zhi a seven-step time (~10 seconds by my guess) to complete the task. To create a couple of real automated tests and set up a Continuous Testing Server, the time limit shall be 4 hours or less, excluding the preparation time such as explaining the test case and test data. The infrastructure support shall be ready for CT as well.

Why time is important? This is to reduce the commitment of the managers. Some fake agile coaches and engineers are good at talking their way out of hands-on practices. The more time the practice takes, the less likely it will get done. In most cases, since the efforts (time and money) have been made, weak-minded managers might think: “It is me who brought him in. By giving him some more time, he might get it working as he said”. Then the manager is more likely to defend his choice/decision from now on.

2. Work on the common goal, no sabotage

The relationship between developers and testers is tense in some software teams. Each group seems to make the other’s life harder. Here are a couple of examples.

• Testers are over keen to raise defects

Once I saw a senior manual tester criticized a newly-on-board tester for talking to the programmer or business analyst (for clarification). In her opinion, just raise a defect when the tester found a mismatch against the user story detail on Jira.

I was shocked. This big financial company has been adopting ‘Agile’ for years. The company engaged in external Agile training, and this team even shared an on-site agile coach with another team.

“Individuals and interactions over processes and tools”

- the first value of Agile Manifesto

Every developer should know that "the earlier a defect is found, the cheaper and quicker for it to be fixed". No one (from my experience) would argue with that. However, a large percentage of developers tend to delay fixing in practice, which is a big waste. Moreover, it makes further testing hard (with many existing unresolved defects).

The root of the above problems is that these testers and developers focus narrowly on their own interests. For testers, the defect count (has been raised); For developers, user story points (implemented this sprint). The sad thing is that customers do not care about these imaginary measurements at all.

It is not surprising that developers often decline (or forget) the request when an automation tester asks a developer to add IDs to page elements (to make test automation easier).

These people forget they are in the same team. The word 'team' is supposed to mean something. All team members should share a common goal, and it is beneficial for each member (technically, financially, and morally) to deliver a high-quality software product.

Ultimately, it is the failure of Executive Management to allow this toxic culture to exist. My advice to CIOs: introduce Continuous Testing to make what really matters obvious. CIO checks the build status every day, like Larry Page, Google’s co-founder and CEO.

Page told an audience in Europe that he gets “a new build” on his Android phone each day. “It continues to work better and better every day.” — “What would Larry Page do? Leadership lessons from Google’s doyen” on Fortune, 2011–04–19

---

The article was originally published on my Medium blog on 2021-11-15.