Code Quality Doesn't Equal Product Success
Solve the real problem for real users; architecture and code quality are nearly orthogonal to success
- Difficulty
- Easy
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 90%
Prasanna's most counterintuitive career lesson: 'a lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other.' Products win by solving a specific real problem for specific people — not by clean architecture. The corollary is to resist the constant engineering urge to refactor, because most code could be thrown away tomorrow, and to allow 'controlled chaos' so talented engineers can experiment.
Origin
Prasanna's lesson, anchored in his firsthand YouTube-vs-Google-Video observation while at Google around YouTube's acquisition.
Core principles
- 01Product success and code quality are nearly orthogonal
- 02Focus relentlessly on the specific problem and the specific person you're solving it for
- 03Most code could be thrown away tomorrow — don't over-invest in its craftsmanship
- 04Refactoring urges are usually misdirected energy away from the real problem
- 05Controlled chaos beats blinkered process: give strong engineers freedom on a foundation that won't rupture
How to run it
- 1
Name the problem and the person
For any product, state exactly whose specific problem it solves (e.g. a Square merchant making a sale). Keep that 'front and center.'
Pro tip 'Just focus on what we're trying to build and whom we're trying to build for.'
- 2
Resist the refactor reflex
When engineers push to rewrite 'in a better way,' weigh it against the fact that the code may be discarded regardless. Only invest in quality where it serves the user need.
Pro tip 'It's not really important how well our Android platform performs unless it's serving that need.'
Watch out Engineers 'continually' argue for refactors; most don't move the product.
- 3
Build a stable foundation, then allow controlled chaos
Bed down the things that can't fail (reliability, not losing money), then let engineers experiment freely — even waste time on dead ends — because that creativity ships the amazing things.
Pro tip Tolerate wheel-spinning if the same engineers also deliver breakthroughs on the flip side.
Watch out Engineers 'can really go off into rabbit holes if you let them' — the foundation must not be liable to rupture.
In the wild
At Google around YouTube's acquisition, engineers were aghast at YouTube's 'horrible' codebase — reportedly storing videos as blobs in MySQL on a slow Python stack. Google Video was better architected, supported more formats, higher resolution, and hour-long uploads; YouTube only had short clips.
→ YouTube 'far and away blew away its competition' and became arguably Google's most successful product, despite the inferior architecture — proving code quality and product success are decoupled.
As head of engineering scaling Cash App from ~10 to 200+ engineers and to 20M+ users, Prasanna let people build random experiments and ship without strict software-lifecycle policies. From outside it looked chaotic.
→ The permissive-but-founded approach let brilliant engineers deliver breakthroughs; he kept it safe by hardening only the things that could rupture reliability or lose money.
Common mistakes
Equating clean code with a winning product
Teams pour energy into architecture and refactors believing it drives success; YouTube shows the two are unrelated and the effort can be wasted.
Harnessing talented engineers into blinkered process
Over-strict lifecycle rules 'do more harm than good' by killing the creative experimentation that produces breakthroughs; the fix is controlled chaos on a stable foundation.
Is it for you?
Best for
Engineering leaders and founders deciding how much to invest in code quality vs shipping problem-solving product
Not ideal for
Safety-critical or high-reliability systems where the foundation itself must be flawless, or contexts where technical debt is actively losing money
From the transcript
“A lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other”
“you could argue that YouTube is the most successful product at Google by a long way... it really has very little to do with how…”
“no this all this code could be thrown away tomorrow. So just focus on what we're trying to build and whom we're trying to build…”
“there's a certain amount of creativity that chaos breeds and you have to know how to build controlled chaos”
From the episode
How Block is becoming the most AI-native enterprise in the world
Dhanji R. Prasanna