A company decided to rename its product XYZ to ABC. Assets, texts in the app, and web pages were updated. Yet whenever an update came, it was installed to "C:\ Program Files\XYZ", not to "C:\Program Files\ABC" folder (or to "/System/Applications/XYZ.app" on Mac). "This is unacceptable," decided the team. "That's sloppy work; we must fix it."
That's how they wasted almost 2 months fighting with renaming the paths while adding 0 useful features… Tinkering their sophisticated self-update system, writing migration logic, migrating user data, some users complaining about app crashes or data being lost… They eventually did it and could confidently say that the renaming was 100% done. After all, what could you have expected from a team of great engineers who seek to do things right in the first place, to be proud of their work?
At about the same time I observed the gradual rebranding of Oculus products (that were acquired by Meta), and how their hardware (Oculus Quest) and software (Oculus Link) received new names. One day my Oculus Link changed its title to Meta Quest Link, there were no more URLs that had 'oculus' in their path, and old links redirected to Meta domains. Yet I could still see the "OculusServer.exe" process in my task manager, and the path to the app was "C:\Program Files\Oculus". Why could this "sloppy" work be tolerated by Meta yet be taken so seriously by a small team of Eastern European engineers?
This perfectionism fallacy, the fundamental approach has often played a trick on teams with excessive focus on engineering and little focus on the product. It's doing things right, rather than doing the right things - having a sharp focus on irrelevancies.
Based on my experience I'm inclined to generalize this as a cultural trait of East European engineers. I have also seen many mentions of East European founders struggling to build successful products. Shyness, communication and presentation skills, not being connected are mentioned as common challenges. IMO, the engineering approach and "doing things right" is also one of the factors. With that much upfront effort and time put into building by the book, one can run out of time.
Speaking of cultural traits (in regards to product engineering), there's another generalization I have recently formed - China.
Recently there's a lot of talk about struggles in Western automotive industry. Chinese auto manufacturers are discussed in (almost) every piece of news on this topic. They managed to iterate fast, introduce new models at an unprecedented pace, and build high-quality cars that are reliable and packed with features. And they produce those cars at a fraction of the costs of traditional automakers.
Take for example Zeekr - an electric car brand owned by Geely. Other owned brands include Volvo, Polestar, Smart, and Lotus. In my opinion, Zeekr cars offer double the value at half the price - compared to European brands. And they have one of the best infotainment systems on the market. Their most recent 001 and 007 models use 15" 3K !!OLED screens as a centerpiece of infotainment. Sidenote, Apple still struggles to put OLED panels into its MacBook Pro and uses inferior Mini-LED tech - the halo artifacts on those panels (when you watch dark videos with bright contrasting objects) are horrible. Yep, Zeekr is OK to put the best in the market screen in every car and they are not greedy enough to charge an extra $2000 for an option as BMW or Audi would…
Why am I bringing Zeekr and their infotainment? It's based on Android 12L (AOSP, Android Open Source Project) and there are plenty of system APKs (navigation, car settings, air con apps, and more). These app files are signed with AOSP Test Keys. When you open the related document it literally says:
"The test keys in this directory are used in development only and should NEVER be used to sign packages in publicly released images (as that would open a major security hole)".
You are reading it right, the company shipping out 25000 cars monthly has this "sloppy" work in every one of them. They didn't even care to take an extra step and generate new keys, a half-an-hour detour for a software developer (and maybe a few days/weeks to get this discipline spread inside their dev organization and infrastructure).
What are the consequences of using test keys? Well, it doesn't seem that their infotainment is buggy (yet it's pleasant to look at if you factor out hieroglyphs), their Active Driving features are great, Zeekr cars have good crash test results and don't bother owners with unwanted repairs or excessive maintenance.
One of the bugs (or features) is that now everyone with access to Zeekr Diagnostic System (official dealer software) can enable ADB and start modding their infotainment system. There's a whole brewing community now, sharing (or selling) their Zeekr app modifications (translations, replacing nav system, integrating music streaming apps). Here's my repo where I share experiments with the Zeekr OS 6: https://github.com/maxim-saplin/zeekr_apk_mod
Cars produced for the Chinese market and exported often don't have a choice of language in their infotainment. Those buying these CDM (Chinese Domestic Market) cars often use Google Translate on their phones to make sense of the UI. Now the mod community hacking into infotainment systems filling the gap and offering UI translations.
Imagine Mercedes launching a new model without ticking a thousand checkboxes first, e.g.:
…
- UI translated to 60 languages: Done
- National approvals received: Done …
"Who cares, that will do" seems like a trait of Chinese product engineering culture which gives them an advantage. Not to be confused with sloppy work.
Top comments (0)