Chinese Idiom Stories for Software Professionals: #07 Be There just to Make Up the Number (滥竽充数)
Expose the fakers quickly.
This article is one of the “Chinese Idiom Stories for Software Professionals” series.
Story
In ancient China, King QiXuan loved to listen to the Yu (an ancient musical instrument, a bit like a Flute), especially in the ensemble. In the palace, there was a band of 300 Yu players. The King often ordered this band to play for him.
A man named NanGuo could not play the Yu. But when he learned of the King’s hobby, he volunteered his service and bragged about how well he could play. He asked for permission to play for the King with other players. King QiXuan granted his request.
Thereupon, in each performance, he would mingle with others, pretend to play, and swindle the same amount of remuneration as paid to others. In this way, he drifted along till King QiXuan died.
King QiMin succeeded to the throne. Under his father’s influence, King QiMin also loved to listen to the Yu. The only difference was that he liked to listen to solos, not ensembles. King QiMin proclaimed that the players must perform one by one for him.
When NanGuo heard of this, he was afraid. He knew he could not drift along with the crowd any longer, so he snuck away that very night.
Meaning
Fraudulent methods can be exchanged for temporary success but not for a lifetime of success. Only by studying hard and making oneself have real talents and practical learning can people achieve real success.
Examples in Software Development
Fakers in software teams are common, in particular in the area of Test Automation and Continuous Testing, which is unfortunate. Ironically, fake test automation and CI/CD engineers can be exposed instantly.
Fake Test Automation Engineer
About ten years ago, I worked on a government project. The new CIO introduced IBM’s Rational Suite, including Rational Functional Tester (RFT). Nick claimed he had developed over 10,000 IBM RFT automated tests and joined as a senior automated tester. However, I never saw him write a single automated test for 6+ months (until I left the organisation). He once shamelessly said this in my presence, “between Zhimin and I, we created these automated tests”.
“Oh, Regular Expression, I know it. It is specific to Ruby.” — Nick, a fake test automation engineer 😱
I regretted not correcting him then, as the worse still was yet to come. Nick showed no interest in learning test automation, instead wanted to be involved with management activities (such as who came to work late, and assigning testing tasks). Somehow, he became the test manager’s assistant. Then, Nick started sabotaging test automation. He and the test manager assigned me to work on an off-site project. I agreed. Then, we had this unbelievable conversation.
Nick: “Zhimin, on this project, you cannot do test automation.” (the test manager concurred).
Me: “Why?”
Nick: “This project requires test report comforming a standard Excel form. So you cannot do test automation”.
Me: “I will provide the standard test report as required. I will perform testing using automated scripts, then generate Excel report using automation scripts.”
Nick: “No, you still can’t”.
Me: “My job title is test automation engineer, performing automated testing is in my job description.”
Test Manager: “We have plans for test automation, and I will offer you a long term contract … ”
Me: “If I am not allowed to do my job, I will resign.”
A few days later, the off-site project manager who had heard of me before asked the director why my assignment was cancelled. The director called the test manager and me in for a meeting, assuring me that I could do test automation on that project. The test manager hardly spoke in the meeting.
On my first day working on the off-site project, I developed a couple of automated tests. The PM was deeply impressed (later he learnt test automation from me), he said: “This is the stuff they forbid you to do; it is crazy!”.
I met many fake test automation engineers. The lesson (from this idiom) is: Let a newly-hired test automation engineer prove themselves on the first day, solo. There are no excuses, as developing End-to-End automated web tests are exactly the same. For the client projects that I can remember when the infrastructure is ready, I could always develop a few real automated tests on the first day.
Fake CI/CD Engineer
Continuous Delivery (CD) is mostly about executing automated tests.
In an interview in October 2019, Lisa Crispin, the co-author of the Agile Testing book, said this: “They (Jez Humble and David Farley) asked me to be a technical reviewer for their manuscript (Continuous Delivery book) … I read it. It’s a book about testing, you know, the whole book is really about testing. That’s the heart of continuous delivery. Jez Humble is very supportive of my saying that.”
It is so obvious. If there is no automated testing, what is the value of delivery?
However, most people got that wrong. Almost every project now claims they are doing “CI/CD” or “CI/CD pipeline” or Continuous Testing (CT). The reality: >99% faked it.
Since 2012, I noted down the automated test pass rate in so-called CI/CD implementations (with 25+ automated tests, over a recent month). The highest pass rate was 48% (excluding my clients’ and own projects). The target pass rate shall be ~100% every day.
Here is a story. I joined a software consulting company that claimed an agile leader. John, the tech leader, told me they have set up a successful CI/CD process using Bamboo. John told me: “We run automated tests every night”. At that time, I knew he was lying or did not understand CI/CD. I decided to lead him to the truth.
Keep reading with a 7-day free trial
Subscribe to The Agile Way to keep reading this post and get 7 days of free access to the full post archives.