Essay Collection — Casual Talks
A year ago I researched the construction of AB platforms; detailed content is summarized inAB problem domain.
My assessment of the current stage. According to the experimentation maturity model, Jingwan is roughly at the walking stage, while other businesses are at the crawling stage. Crawling is the first stage in the maturity model; earlier than that I would call it awakening or enlightenment. The goal of the crawling stage is to establish basic experimental conditions, especially tools and fundamental data science capabilities.
AB platforms that are relatively advanced within the company. I had focused exchanges with the team platform Horizon and the home-delivery fulfillment AB platform. They are roughly at the running stage, and their evolution aims to reduce experimentation barriers at scale and ensure experimental confidence. They avoid having experimenters spend excessive effort on proving solutions or having human factors undermine experiment reliability. They introduced data-science-related roles. From the metrics, you can tell they consider access, traffic splitting, implementation, and decision-making holistically—for example, the platform’s objective assessability rate for new experiments and the objectivity rate of important experiment results.
Lessons from the development history of the home-delivery fulfillment AB platform. This information comes from my conversation with one of its core members; in my view it is a typical example of a technology-for-service business. What they iterated continuously was the specific relationship between technology and business, and the most valuable aspect was the mindset and talent of “business-technology integration.”In such specialized domains, the business cannot clearly articulate problems and sometimes is unaware of them. To serve the business well, you must step outside your own domain, go to the front line, understand the business, and shift perspectives. Fulfillment is central to home delivery, so improving fulfillment efficiency is crucial. LBS’s multi-sided model requires extensive algorithm and strategy experiments, which drives a stronger demand for a high-quality AB experimentation platform. Initially the platform operated loosely coupled with the business, with a lightweight platform feel. 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 capabilities but solutions—capabilities, tools, methods. In deep-challenge areas, fulfillment also explored early collaboration with research teams. For openness, the fulfillment AB provides three levels: fully managed platform, semi-managed platform, and an open analysis engine—corresponding to unified platform management, opening of experiment design and evaluation capabilities, and opening at the atomic analysis-method granularity.
Recently I reviewed a component library initiative and tried to answer a vague question: how does a component library become truly vibrant? Component libraries are very common; generally the idea is clear and simple, but those that become popular, useful, and long-lived are few—especially long-lived ones. I attempted to answer from two perspectives.
Solve real problems within a defined scope and maintain a positive input-output ratio.
Identify the real problems within the target value level, and after thorough research, actually solve them. Focus on the scope of problems being addressed, because different scopes entail different costs and solution choices. For example, component libraries aimed at Meituan, financial services, or internal team use may have different target values.
For projects with inherently limited value potential, you must constantly watch the input-output ratio, because maintenance costs can quietly exceed real value—this will be corrected over the medium to long term. Recently people lamented that YAPI, an interface-mocking tool with a better experience, stopped being maintained while PAPI remains the official recommendation. Regardless of organizational differences between the two tools, from an input-output perspective I suspect YAPI’s maintenance costs have exceeded the incremental experience value it provided developers. I have no hard data; the fact that most projects did not migrate to YAPI supports the idea that the experience gain was marginal and likely didn’t offset migration costs.
Solve problems at the correct level of abstraction.
The true problem is the essence of the issue plus its scope. A component library is already a solution; at higher abstraction levels a component library may not be optimal. As abstraction increases, solutions can be roughly categorized as implementation, library, framework, and standard. A component library is the second-level abstraction, and I think this explains why MTD failed. There is a community project calledA Global Design Systemwhose vision is to provide universal components to designers and developers worldwide. In fact, it is not merely a component library; it is a system, but not a design system like Material Design. Projects like this need not worry about whether they succeed; the point is to learn how to explore a proposition at a high level of abstraction.
Technical matters in business teams can be divided into two major categories. One is solving prominent immediate problems, requiring concentrated effort to tackle them, often advanced as technical initiatives. The other is long-term construction and operation—things like component libraries and infrastructure. These require continuous, sustained effort and often lack suitable operating mechanisms. In fact, the operating mechanism itself can partially answer how to maintain infrastructure vitality and longevity.
As team size grows and engineering foundations strengthen, our work emphasis must gradually shift from episodic efforts to long-term sustainable practices.
Our infrastructure has passed the 0-to-1 phase and now must explore 1-to-infinity experience. Current operating mechanisms are relatively closed, which breeds dependence on individuals. Contribution enthusiasm inside the team is low and depends on administrative directives. My idea is to learn from mature open-source projects, establish open and sustainable operating mechanisms, and unlock team creativity.
Draft versionWorking Group. We adopted the Working Group concept and introduced mechanisms like RFCs and Membership. At the same time, we tailored and trimmed these mechanisms to balance efficiency and openness for our team size. Colleagues with ideas are welcome to provide feedback.
Recently, with business adjustments on the ledger, both frontend and backend face questions about architectural rationality. Architecture rationality directly reflects on quality; the refactor of business-critical systems started from this. Here are some thoughts on frontend business architecture.
Architecture is an asymmetrical concept between frontend and backend. In frontend, consensus on business architecture design is less developed; conversations tend to focus on frameworks and toolchains. One reason may be that the frontend faces fewer architectural challenges. Bottlenecks caused by business-architecture decisions often never appear in many projects’ lifecycles; a generic scaffolded engineering setup can meet 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 final deliverable folder structures and documentation risks overlooking important architecture concepts such as isolation and reuse, state management, and dependency inversion—areas that affect real quality and business support. For example, the ECS architecture in gaming addresses domain-specific maintainability issues.
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—Conway’s Law aside. Two points are worth noting. First, overall architecture design will increasingly consider the frontend. We are still in the phase where niche languages must make mainstream languages understand their work, but we already see quality and efficiency considerations including the frontend (though technical risk-control exams still feel like off-duty theoretical tests). Architecturally, the 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 component-as-service mindset.
Must-read for understanding frontend architectureWhat is Frontend Architecture?, keep following the author Tomasz Ducin for ongoing insights in this field.
On physical limits, engineering limits, and experience limits. I’ll try to answer an observation from last week: when we talk about optimization, what level are we optimizing at, and within what boundaries do we optimize?
Understanding physical limits clarifies fundamental constraints, helping maintain clear judgment during complex innovation processes and make wiser resource investments. There are still amateur inventors pursuing perpetual motion, but Carnot in the 19th century already proved theoretical limits on heat-engine efficiency, so perpetual motion is futile. Some now claim AI will solve all problems and replace humans; Turing in the 20th century already provides a clear answer. Many world problems are not mathematical; only a small subset are, and an even smaller subset are solvable, and an even smaller subset are computable by Turing machines, and an even smaller subset are feasible on existing computers. Problems AI can solve are a subset of those. Physical limits are nearly impossible to overturn; mathematical limits are effectively immutable because mathematics is strictly logical rather than empirically observed.
Engineering limits give direction and efficiency to practice. Within known physical boundaries, multidimensional optimization improves performance and finds engineering optima. For example, DVDs using blue laser instead of red exploited blue’s shorter wavelength for greater capacity. From 2G to 6G, developments did not break Shannon’s theoretical channel-capacity limits for given bandwidth and SNR; each generation applied engineering optimizations in spectrum, coding and modulation, and network architecture. Moore’s Law continues, and as silicon approaches its material limits we see engineering improvements via 3D stacking packaging, SoC and heterogeneous-compute architecture optimizations to keep raising performance.
Experience limits remind us this is an infinite game—experience plays with boundaries. Human needs, expectations, and imagination constantly evolve; no matter the technological progress, experience optimization around MOT and human factors is never finished. Therefore there is no point where technology progresses enough that optimization becomes unnecessary.
I read Cash Is King. Revenue is ephemeral, profit is wise, but cash is sovereign. This is especially applicable in today’s stock-market-dominated era where efficiency rules. Competition is no longer pure scale expansion or growth chasing, but deep excavation of efficiency.
The book uses weight management as an analogy for the “cash is king” logic.
Use a smaller plate. Frugality: constrain operating costs within a reasonable, finite resource. Parkinson’s Law suggests demand for something grows to fill its supply. That’s why expanding roads to reduce congestion never works—more drivers will fill the added lanes.
Eat vegetables before carbs. Rewrite the classic accounting formula “revenue − costs = profit” as “revenue − profit = costs.” Carve out profit first, then decide how to spend the remainder. This is based on the primacy effect.
Eliminate temptation; hide what should not be consumed. Put reserved profit, shareholder returns, taxes, etc., into a separate account that is not convenient to withdraw from.
Small, frequent portions to shave peaks and fill valleys. Check bank balances twice a month and infer operating conditions from available cash—the simplest bank-balance bookkeeping method.
I recalled Apple’s redesign of sleep management and the alarm, though I can’t remember which iOS introduced it. Typical alarm logic focuses on wake time. Apple’s sleep alarm interaction asks users to prioritize a sleep-duration goal, then adjusts bed and wake times to meet that goal. This is an example of a conceptual shift reflected in product design; profit-first thinking should cast similar effects in personal finance ledgers.
The semi-floating checkout refactor and its ramp-up has been an unresolved issue for a long time; now it’s time for a decisive push. Facing a problem that has worn down the team’s will for nearly a year, I have two choices: I either solve it myself, or I lead people to solve it. From a management competency perspective, the organization expects me to lead people to solve it. Leading the team requires I think through in sequence: mindset, people, goals, and strategy. The first thing to address is mindset restructuring: with what attitude and disposition should we face the same challenge, create new approaches, and communicate them to the team?
I happened upon a new book, Reframe Your Brain. To reframe is to reset the frame and actively interpret reality as a new story that is more useful to you. It is reprogramming the brain, like an FPGA. Psychology has a similar concept—cognitive restructuring: given a situation, experience, thought, or emotion, identify how you view it, then challenge that view and adopt a different perspective. For example, view difficulty as a challenge, a challenge as an adventure, and adventure ultimately as a game.
The book covers many reframing techniques; an important one is transforming a passive mindset into an active one. Years ago Jerry told me something similar: shift from 'what I am told to do' to 'what I want to do.' Further, move from 'I want to (want to) do something' to 'I decide to do something.' A decision is absolutely active; it is a commitment to oneself. Wanting to do something can fade if circumstances change. Deciding to do something makes you find ways to accomplish it—nothing can easily stop you.
Is mindset restructuring just feel-good 'spiritual victory' self-help? It’s like marketing versus pyramid schemes: both sell something on the surface, but the true difference is who creates final value. The value of a reframed narrative is not whether it’s objectively true but whether it is effective for you. Some narratives may not be strictly correct, yet if they are effective for you, that’s sufficient.
Last week a checkout integration case showed that due to platform container limits, the business was forced to switch checkout product types, incurring significant communication costs. We used the opportunity to review historical impacts of platform-container switches on the business. Lining them up chronologically highlighted the core issues. As tiange’s signature phrase advises, 'strive to avoid object vagueness, simplification of standards, and mechanization of actions during standardization.' I believe 'object vagueness' is the most prominent problem. Financial services may be the largest client of standardized containers; historically many technical decisions were made without proactive frontline research or interviews. Designs made after deeply engaging with the business are the pragmatic ones.
The platform’s technical products or standards generally cover about 90% of scenarios well. The remaining 10% of long-tail scenarios are the headache—they usually exist because of 'not knowing' and require the business to patch design gaps via experience or cost. Our feelings and evaluations of platform work are determined by that last 10%—achieving 90% of the journey is not enough. Quality control’s Six Sigma concept suggests that to reach high-level outcomes, process capability must be at six sigma. You must focus on eliminating the final, hard-to-detect design defects; attention to and resolution of edge long-tail issues produce significant quality improvements or competitive advantage.
This should serve as a lesson and a reminder for us to pay extra attention when creating standards and governance.
Last updated