The ‘Wrong Question’ Philosophy: How Perfetto’s Lead Engineer is Redefining Tooling Support
Table of Contents
Beyond the Ticket: The Psychology of Technical Support
In the high-stakes world of systems engineering, the request for a new feature is often a symptom of a deeper misunderstanding. For Lalit M, a primary engineer working on Perfetto—the powerful system-wide tracing tool used across Android and Linux—the most dangerous part of a support request is the first question asked.
The premise is simple but counterintuitive: when a user asks for a specific technical workaround, the answer is rarely the solution. Instead, the request serves as a signal that the user’s mental model of the tool is misaligned with how the tool was designed to function. By refusing to answer the initial question, M aims to uncover the ‘why’ behind the request, turning a routine support ticket into a strategic insight into product friction.
The Trap of the ‘XY Problem’
Software developers are familiar with the ‘XY Problem,’ where a user wants to achieve X, decides that Y is the way to do it, and then asks how to do Y. Most engineers treat this as a decoding puzzle—solve for X and move on. However, M argues that this approach is insufficient.
According to M, the confusion that leads to the wrong question is an opening. When a user asks how to split a massive Perfetto trace into multiple smaller files, the direct answer is that there isn’t an easy way to do it. But the real question is: why is the user collecting traces so large that they feel the need to split them?
By probing the context, M often discovers that the user is attempting to use a trace as a general-purpose metric collection system—trying to calculate frame rates or memory usage by counting events in a massive recording. This is a fundamental misunderstanding of the tool’s philosophy. Traces are resource-intensive; using them to sample a single number is inefficient. A dedicated metric system is the correct tool for that job, not a trace split into pieces.
Designing for the ‘Missing Philosophy’
This approach highlights a recurring tension in the development of complex gadgets and software tools: the gap between a feature’s power and a user’s ability to harness it. Perfetto is designed to be exhaustive, but that power can be overwhelming. Many teams approach the tool with a predetermined idea of how it should work, leading them to file feature requests for capabilities that already exist under a different name or logic.
Take the case of long-term recordings. A user might request better slicing tools for a long trace, unaware that Perfetto already supports periodic trace snapshots—short, repeated recordings that eliminate the need for a single, gargantuan file. In this instance, the ‘feature request’ was actually a request for education on the tool’s existing architecture.
The High Cost of Fast Implementation
For those building foundational software, the cost of implementing the wrong feature is far higher than the cost of delaying a release. M suggests a philosophy of strategic hesitation: avoiding the build of a new feature until the pain of its absence is felt by multiple, independent teams.
This cautious approach prevents ‘feature creep’ based on the idiosyncratic needs of a single user who may not fully grasp the system’s constraints. By waiting for a pattern to emerge across different users, the engineering team can identify the essence of the problem and build a robust, scalable solution rather than a series of ad-hoc patches.
Ultimately, the goal isn’t just to provide a functioning tool, but to teach the industry how to approach performance engineering. By shifting the conversation from ‘how do I do this’ to ‘why are you doing this,’ M is not just debugging code—he is debugging the user’s approach to the problem itself.
