Reflections on China's Transformation of the Car Industry, Part F: Lacking on Plan B and C 👎🏾
Wise executives experiment, learn, adapt, and always plan for the worst
Agile software development, rooted in Lean car manufacturing principles, emerged during a pivotal revolution in the 1980s. Now, we are witnessing another, much greater, transformation in the automotive industry—one that may offer valuable lessons. In this series:
Part A: The Disruptions
Part D: Traditional Car Manufacturers Reluctant to Evolve 👎🏾
Part F: Lacking on Plan B and C 👎🏾
Part G: Acknowledge Mistakes
Traditional car manufacturers are in serious trouble right now, and you’ve probably seen headlines like the ones below in major media.
The worst is yet to come.
Why have the highly-paid executives at traditional car manufacturers done so little over the past decade? This isn't an unexpected firestorm; it's as if they've been watching the rising water levels submerge them and chose to do nothing.
Logically, where were plan Bs and Cs?
Steve Jobs’ Plan Bs
Steve Jobs is widely regarded as the best (not just one of the best) CEO in recent decades. What impresses me most is how he always Plan Bs, for example, transitioning CPU architecture, twice!
Power-PC → Intel CPU
Intel → Apple Silicon (ARM64)
You don't have to be a skilled software professional to understand how monumental this task was. The two Plan B projects (which occurred at different times, sequentially) were carried out in secret for years. Just think about it—every new feature implemented in the current macOS had to be adapted by the Plan B team. On top of that, the Plan B teams had to develop a mechanism to ensure that most apps (designed for the current CPU architecture) would work on the new architecture.
Yes, Apple did it—twice. Without the courageous and unwavering commitment of Steve Jobs, this would not have been possible.
Doing Show-Ponies is not enough
As I wrote in a previous article, Honda, Nissan, … etc have all produced some EV prototypes. However, it all turned out to be just show ponies. A company’s culture is a reflection of its top executives.
Why did Apple products, during Steve Jobs's time, generally have a better quality than the industry average? You can find reasons in his famous quote below.
Here's an unverified story about Apple's quality that I heard. After my talk at the StarWEST conference in 2013, several attendees surrounded me with questions. During the conversation, one shared, 'My friend worked at Apple. Steve Jobs wanted to create the fastest web browser (later known as Safari). The team had a policy: any code check-in that caused the automated test suite to run slower would be automatically rejected. At first, the programmers hated it, understandably. But over time, they came to appreciate it, as it truly contributed to the success of the Safari browser. (without Safari, there was no iPhone)'
What happened at those traditional car manufacturers was that the staff sensed the CEO's lack of passion for EVs and responded accordingly.
Does your team have Plan B or C for Implementing Automated E2E Test Automation?
Back to the main topic of this newsletter: E2E Test Automation. One strange thing I've observed is that nearly all companies have made several attempts at E2E test automation, and all have failed. Typically, there are three or four year gaps between these attempts. Through conversations, I could sense that 'failure is acceptable' to the senior engineers there.
When I had the chance to examine those failed attempts, I noticed a common pattern: they would spend a few months (typically around 3) working with a specific technology stack chosen by a senior engineer (or external agile coach), and ALL incorrect choices, such as:
Microfocus UFT and other expensive tools that typically rely on record-and-playback
Selenium WebDriver + Cucumber
WebDriverIO (JS)
Protractor
Cypress
Playwright
Web test automation is universal for all websites, and web technologies barely changed over the last two decades. In other words, if one test automation engineer did one successful web test automation, it then pretty much copy-n-paste. Check out my article, My Core Test Automation Stack Largely Unchanged for 17 years.
During my consulting and coaching sessions, after the introduction, I ask the BA or tester to show their main business test scenarios, and I then script the automated tests for them, on the spot, live. Some QA professionals and senior software engineers were deeply impressed by the efficiency. When they ask how I could do it, my answer is: “I’ve been doing this exactly the same for over a decade.”
I'm not saying that my approach and tech stack are the only solutions for effective E2E test automation. I know, from published information, that Facebook successfully implemented E2E test automation using Watir and later Selenium WebDriver, though I’m not familiar with their specific details.
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.
If a software company is open-minded about frameworks, scripting languages, and tools when attempting E2E test automation, they will discover and learn valuable insights, as outlined below
JavaScript is not a good language for E2E test automation, drop it.
Jenkins is only good for executing unit tests, not E2E tests, drop it.
…
As I mentioned before, web test automation is generic and can yield results in just a few days. So, an open-minded E2E test automation attempt with Plan B and C is very likely to lead to a good solution. However, sadly, this common sense is rarely applied in practice. People often become fixated on a specific technology, and once they make a decision, they are unwilling to adjust—much like the car manufacturers currently facing trouble.
Related reading: