Essay Collection — Miscellaneous Talks
Before the New Year I researched the construction of AB platforms; detailed content is summarized inAB problem domain.
Assessment of the stage we are in. From the experimental maturity model, Jingwan is approximately at the walking stage, while other businesses are at the crawling stage. Crawling is the first stage of the maturity model; earlier stages I would call awakening or enlightenment. The goal of the crawling stage is to build basic experimental conditions, especially tools and fundamental data science capabilities.
AB platforms in the company that are further along. I had focused exchanges with the team platform Horizon and the at-home fulfillment AB platform. They are roughly at the running stage, and their evolution aims to scale down experiment barriers and ensure experiment confidence. They avoid having experimenters spend most energy on validating schemes and on human-factor confidence issues. They introduced data-science-related roles. From the metrics you can tell they view the process holistically—onboarding, traffic splitting, execution, and decision-making. For example, platform metrics like the objective determinability rate for newly onboarded experiments, and the objectivity rate for important experiment results.
Lessons from the development history of the at-home fulfillment AB platform. This information comes from my conversation with one of its core members; to me it is a typical example of a technical service business. The ongoing iteration of the business-technology relationship is valuable, and most precious is the mindset and talent of “business-technology integration.”In such a specialized domain, the business cannot clearly describe problems and sometimes doesn't even recognize them. To serve the business well, you must leave your own domain, go to the front line, understand the business, and shift perspective. Fulfillment is core to at-home services, so improving fulfillment efficiency is crucial. LBS’s multilateral model requires many algorithm and strategy experiments, so the demand for a high-quality AB experimentation platform is stronger. Initially the platform operated loosely coupled with the business, showing a lightweight platform character. In 2022 it shifted to focus on serving fulfillment, offering fully managed services. The business only needs to submit requirements; experiment design, execution, and analysis are closed-looped within the data team. They provide not just capability but solutions—capabilities, tools, methods, etc. In deep, high-challenge areas, fulfillment also early explored research collaboration. Regarding openness, the fulfillment AB offers three openness levels: fully managed platform, semi-managed platform, and an open analysis engine. These correspond to unified platform management, opening experiment design and evaluation capabilities, and opening atomic analysis-method granularities, respectively.
Recently I reviewed a component-library initiative and tried to answer a vague question: how to become a highly vital component library? Component libraries are common and usually straightforward to explain, but very few become popular, useful, and long-lived—especially long-lived. I try to answer from two perspectives.
Solve real problems within a defined scope while keeping a positive input-output ratio.
Identify the real problems you face at the level of target value; after thorough research, solve those real problems. Focus on the scope of problems you address—different scopes entail different costs and solution choices. For example, a component library targeting Meituan, a financial-services team, or an internal team will have different target values.
For projects whose potential value is inherently limited, you must be vigilant about the input-output ratio, because maintenance costs can unknowingly exceed real value, which will be corrected over the medium to long term. Recently people lamented that YAPI, an API mock tool with a superior experience, stopped maintenance while PAPI remains the official recommendation. Regardless of organizational differences between the tools, from an input-output perspective I suspect YAPI’s maintenance costs surpassed the incremental experience value it gave developers. I have no hard data; the fact that most projects didn’t migrate to YAPI supports the view that the experience gain was marginal and may not have offset migration costs.
Solve problems at the correct level of abstraction.
The essence of the problem plus its scope is the real problem. A component library is already a solution; at some higher scopes it may not be optimal. As abstraction increases, solutions can be roughly categorized as implementation, library, framework, and standard. The component library is the second abstraction level; I think this explains why MTD didn’t succeed. There is a community project calledA Global Design Systemwhose vision is to provide universal components for designers and developers worldwide. In fact it isn’t a component library; it’s a system, and not exactly a design system like Material Design. Projects like this need not worry about whether they succeed; the key is learning how to explore a high-abstraction proposition.
Technical matters for business teams fall into two categories. One is solving pressing problems at the current stage, which requires concentrated efforts and is usually advanced as technical initiatives. The other requires long-term construction and operation, like component libraries and infrastructure—these are continuous, needing steady, long-term work and suitable operating mechanisms. In fact, such operating mechanisms partly answer the important question of how to keep infrastructure active and vital.
As team size grows and engineering foundations solidify, our focus must shift from episodic efforts to sustainable, long-term work.
Our infrastructure has moved from 0→1; we now need to explore 1→∞ experience. Current operating mechanisms are closed and therefore rely on individuals. Contributions within the team are low and depend on administrative directives. My idea is to learn from mature open-source projects, establish an open and sustainable operating mechanism, and stimulate team creativity.
Draft versionWorking Group mechanism Working GroupWe adopted the Working Group concept and introduced RFC and Membership mechanisms. We also tailored and customized them to balance efficiency and openness given our team size. Colleagues with ideas are welcome to give feedback.
Recently, with business adjustments to the ledger, both frontend and backend face questions about architectural rationality. Architectural soundness directly affects quality; the reconstruction of the business platform’s bottlenecks started from this. Here are some thoughts on frontend business architecture.
Architecture is not symmetric between frontend and backend. There is not yet broad consensus on frontend business architecture; discussions often focus on frameworks and toolchains. One reason may be that frontend faces fewer architectural challenges. Bottlenecks from business-architecture decisions may never appear in many project lifecycles, and a generic scaffolded engineering setup often meets business ceiling requirements.
What counts as an architectural decision, and what does not? Architecture is the result of communication, analysis, and reasoning—not merely tool choice. Focusing only on delivered directory structure and docs risks overlooking important architectural concepts like isolation and reuse, state management, and dependency inversion—areas more related to actual quality and business-support capability. For example, the ECS architecture in games addresses maintainability issues in that domain.
Is it necessary to separate frontend and backend architecture, or is a single general architecture team sufficient? This is a complex question; system structure naturally reflects team communication patterns—I'll omit Conway’s Law details. Two viewpoints: first, overall architecture design will progressively include frontend considerations. We are still in a phase where niche languages are helping mainstream languages understand the work; quality-and-risk assessment has begun to consider frontend (even if technical risk control exams still feel like remote, theoretical tests), so architectural consideration for frontend is not far off. Second, frontend and backend can learn from each other. Frontend can benefit from backend design ideas like DDD to better understand business problems. Backend can learn frontend’s efficient prototyping methods and the mindset of components-as-service.
Essential reading for understanding frontend architectureWhat is Frontend Architecture?—follow author Tomasz Ducin for ongoing insights in this area.
On physical limits, engineering limits, and experience limits. I tried to answer an observation from last week: what level are we optimizing at, and within what boundaries do we optimize?
The significance of physical limits is to understand fundamental constraints, stay clear-headed during complex innovation, and make wiser resource investments. There are still amateur scientists pursuing perpetual motion, yet Carnot in the 19th century proved theoretical limits for heat-engine efficiency, so perpetual-motion efforts are futile. Some believe AI will solve everything and replace humans; Turing in the 20th century already provides a clear perspective. Many problems exist in the world—only a small part are mathematical problems; of those, only some are solvable; of those, only some are Turing-computable; of those, only some are achievable by existing computers—AI-solvable problems are a subset of this chain. Physical limits are nearly impossible to overturn; mathematical limits are impossible to overturn because mathematics is built strictly on logic rather than empirical observation.
The significance of engineering limits is to make engineering practice more directional and efficient. Within known physical boundaries, we improve performance through multidimensional optimization to find engineering optima. For example, replacing red light with blue-enabled DVD used shorter wavelengths to achieve higher capacity. From 2G to 6G, there was no violation of Shannon’s theoretical channel-capacity limit given a certain bandwidth and SNR—each generation improved via spectrum, coding/modulation, and network-architecture engineering. Moore’s Law still plays out; as silicon material physics approach limits, we find engineering improvements via 3D stacking packaging, SoC and heterogeneous-compute architecture optimizations to keep performance increasing.
The significance of experience limits is to recognize this as an infinite game: experience plays with boundaries. Human needs, expectations, and imagination constantly evolve, so no matter how advanced technology becomes, optimizing for moments of truth and human factors is never finished. Therefore there is no stage where technology development makes further optimization unnecessary.
I read Cash Is King. Revenue is ephemeral, profit is prudent, but cash is sovereign. This is especially apt in today’s era of stock economies where efficiency rules. Competition is no longer just scale expansion or growth chasing; it’s deep efficiency extraction.
The book uses weight management to analogize the logic of “cash is king.”
Use a smaller plate. Frugality: constrain operating costs within reasonable finite resources. Parkinson’s Law says demand for something expands to fill its supply. That’s why widening roads never solves congestion—more drivers will fill the expanded lanes.
Eat vegetables before carbs. Rewrite the classic accounting formula “revenue − operating costs = profit” as “revenue − profit = operating costs.” Set aside profit first, then decide how to spend the remainder. This follows the primacy effect.
Eliminate temptations; hide what shouldn’t be consumed. Put reserved profit, shareholder returns, taxes, etc., into a separate account that is inconvenient to withdraw from.
Eat smaller, more frequent meals to smooth peaks and valleys. Check bank balances twice a month and infer operating status from available cash—the simplest bank-balance bookkeeping method.
I was reminded of Apple’s redesign of sleep management and the alarm interface—can’t recall which iOS version introduced it. Typical alarm logic focuses on wake-up time. Apple’s sleep alarm interaction has users set a sleep-duration goal first, then adjust when to go to bed and when to wake up. This is an example of a conceptual shift projected into product design—prioritizing profit should be reflected similarly in small ledgers.
The semi-floating checkout reconstruction and its rollout has been an unresolved issue for a long time; now it’s time for a decisive confrontation. Facing a task that has worn down the team’s will for nearly a year, I have two choices: I solve it myself, or I lead people to solve it. From a competent-manager perspective, the organization expects me to lead people to solve it. Leading a team to tackle it requires me to think through sequence: mindset, people, goals, and strategy. The primary issue to resolve is mindset reframing. With what attitude and disposition do we face the same challenge, produce new facets, and convey them to the team?
I happened upon a new book, Reframe Your Brain. To reframe means to reset the frame—actively reinterpret reality as a new story that is more useful to oneself. It’s like reprogramming the brain, akin to an FPGA chip. Psychology has a similar concept called cognitive restructuring: when facing a situation, experience, thought, or emotion, identify how you see it, then challenge that view and adopt a new one. For example, see difficulty as a challenge, a challenge as an expedition, and the expedition as a game.
The book introduces many reframing techniques; one important one is turning a passive mindset into an active one. Years ago Jerry said something like this to me: change from “I am told to do something” to “I decide to do something.” Further, move from “I want to do something” to “I decide to do something.” A decision is absolutely active—a commitment to oneself. Wanting can evaporate when conditions change. Deciding to act makes you find ways to achieve it; nothing will stop you.
Is mindset reframing just feel-good “spiritual victory” rhetoric? This resembles marketing versus pyramid schemes: both sell something superficially, but the real distinction is who creates ultimate value. Reframed narratives aren’t judged by truthfulness alone but by effectiveness. Some reframes may be inaccurate, yet if they work for you, they’re valid.
Last week a checkout-product onboarding case forced the business to switch checkout-product types because of platform-container limitations, creating significant coordination costs. We took the opportunity to map historical impacts of platform-container switches on the business along a timeline; key issues surfaced. As Tiange’s signature says, “Do your best to avoid object abstraction, oversimplification of standards, and mechanization of actions in the standardization process.” I think “object abstraction” is most prominent. Finance is probably the largest customer of standard containers; historically many technical decisions were made without proactively interviewing our frontline colleagues. Designs made with deep business immersion are the pragmatic ones.
Technical products or standards promoted by the platform usually cover 90% of scenarios well. The tricky part is the last 10% of long-tail scenarios, usually caused by “not knowing” and requiring the business to bridge design gaps via experience or cost. Our perception and evaluation of platform work is precisely decided by that final 10%—ninety miles of a hundred is only half the journey. Thinking of Six Sigma in quality control: to achieve high-level results process capability must reach six sigma. Focus on eliminating the last, hard-to-detect design defects; attention to and resolution of edge long-tail issues produce significant quality improvements or competitive advantages.
A lesson to heed—this is something we must be especially careful about when working on standards and governance.
Last updated