korrents

← Topics

Should software be one program or many small services?

Top voices on software quality: Martin Fowler, David Heinemeier Hansson, Dan Luu, Thuan Pham, Steve Yegge.

Most say start with one program; they differ on when to split it, and why.

10 dated claims from 5 people · 3 views · most recent 1 Apr 2026

The views

Our reading of what a group of claims have in common, one level above a korrent: a korrent is our reading of what somebody said, a view is our reading of what several korrents share. The claims are printed under it, so the sentence can be checked against them.

Nobody is filed under a view — claims are. A person is named here because a dated claim of theirs sits under it, and somebody whose claims sit under two views appears under both.

  1. Start with one program, because most systems never need more and splitting early is costly

    David Heinemeier HanssonDan LuuMartin Fowler

  2. Services answer how teams grow, not how the code should be shaped

    Thuan Pham

  3. A codebase too large for a model to hold has to be split, whatever it cost before

    Steve Yegge

A viewour reading

Start with one program, because most systems never need more and splitting early is costly

6 claims filed here, newest first — each in the words of whoever said it.

Microservices for a team of twenty on half a million lines of code is idiotic: the first rule of distributed programming is do not distribute your programming.

  1. David Heinemeier Hansson Creator of Ruby on Rails, CTO of 37signals When you're at Netflix scale, when you apply that pattern to a team of 20 programmers working on a code base of half a million lines of code, you're an idiot. You just don't need to turn method invocations into network calls. It is the first rule of distributed programming. Do not distribute your programming. DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com · 12 Jul 2025 · 2:06:59 into the videoAll korrents from this video
    Their wordsWhen you're at Netflix scale, when you apply that pattern to a team of 20 programmers working on a code base of half a million lines of code, you're an idiot. You just don't need to turn method invocations into network calls. It is the first rule of distributed programming. Do not distribute your programming.

    Where this was said

    Watch from 2:06:59 plays here

    ↗DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com

    12 Jul 2025 · video · 6h 08m · spoken · official transcript

Show all 6 claims

Microservices pose perhaps the biggest siren song for needlessly complicating your system.

  1. David Heinemeier Hansson Creator of Ruby on Rails, CTO of 37signals in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. Even Amazon can't make sense of serverless or microservicesworld.hey.com · 4 May 2023All korrents from this piece
    Their wordsin practice, microservices pose perhaps the biggest siren song for needlessly complicating your system.

    ↗Even Amazon can't make sense of serverless or microservicesworld.hey.com

    4 May 2023

Even at top-100 traffic levels most applications can be served by a simple monolith, and it is cheaper to build than a complex architecture.

  1. Dan Luu Programmer who has worked on hardware verification at Centaur computers are fast enough that high-traffic apps can be served with simple architectures, which can generally be created more cheaply and easily than complex architectures In defense of simple architecturesdanluu.com · 6 Apr 2022All korrents from this piece
    Their wordscomputers are fast enough that high-traffic apps can be served with simple architectures, which can generally be created more cheaply and easily than complex architectures

    ↗In defense of simple architecturesdanluu.com

    6 Apr 2022

Successful microservice systems almost always began as a monolith that grew too big, and systems built as microservices from scratch end up in serious trouble.

  1. Martin Fowler Chief scientist at Thoughtworks and author of Refactoring Almost all the successful microservice stories have started with a monolith that got too big and was broken up MonolithFirstmartinfowler.com · 3 Jun 2015All korrents from this piece
    Their wordsAlmost all the successful microservice stories have started with a monolith that got too big and was broken up

    ↗MonolithFirstmartinfowler.com

    3 Jun 2015

Build a new application as a monolith first, even when you are confident it will eventually need microservices.

  1. Martin Fowler Chief scientist at Thoughtworks and author of Refactoring This leads to a powerful argument for a monolith-first strategy, where you should build a new application as a monolith initially, even if you think it's likely that it will benefit from a microservices architecture later on. MonolithFirstmartinfowler.com · 3 Jun 2015All korrents from this piece
    Their wordsThis leads to a powerful argument for a monolith-first strategy, where you should build a new application as a monolith initially, even if you think it's likely that it will benefit from a microservices architecture later on.

    ↗MonolithFirstmartinfowler.com

    3 Jun 2015

Service boundaries cannot be got right at the start, and moving functionality between services is far harder than moving it inside a monolith.

  1. Martin Fowler Chief scientist at Thoughtworks and author of Refactoring But even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. MonolithFirstmartinfowler.com · 3 Jun 2015All korrents from this piece
    Their wordsBut even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning.

    ↗MonolithFirstmartinfowler.com

    3 Jun 2015

A viewour reading

Services answer how teams grow, not how the code should be shaped

3 claims filed here, newest first — each in the words of whoever said it.

Uber's thousands of microservices were not an architectural preference but a survival decision: under that growth only independent, unblocked teams could build fast enough to stay alive.

  1. Thuan Pham Uber's first Chief Technology Officer, from 2013 to 2020 none of us wanted to go through that extreme but lots of time when you are under a lot of pressure and no time to react other than just to survive that scale that keep on coming at you, you have to make uh decision that increase uh speed and velocity because speed and velocity allow us to build quick enough to survive Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com · 1 Apr 2026 · 0:50:30 into the videoAll korrents from this video
    Their wordsnone of us wanted to go through that extreme but lots of time when you are under a lot of pressure and no time to react other than just to survive that scale that keep on coming at you, you have to make uh decision that increase uh speed and velocity because speed and velocity allow us to build quick enough to survive

    Where this was said

    Watch from 0:50:30 plays here

    ↗Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com

    1 Apr 2026 · video · 1h 39m · spoken · machine transcript

Show all 3 claims

Breaking up a monolith takes years rather than months not because the work is hard but because the business keeps adding to it faster than you can pull pieces out.

  1. Thuan Pham Uber's first Chief Technology Officer, from 2013 to 2020 had we freeze time, that piece of code could be decomposed in a matter of 3 to 6 months. But it took us 2 years to do that because as we peel out a piece of code, the business keep on going forward, right? Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com · 1 Apr 2026 · 0:51:23 into the videoAll korrents from this video
    Their wordshad we freeze time, that piece of code could be decomposed in a matter of 3 to 6 months. But it took us 2 years to do that because as we peel out a piece of code, the business keep on going forward, right?

    Where this was said

    Watch from 0:51:23 plays here

    ↗Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com

    1 Apr 2026 · video · 1h 39m · spoken · machine transcript

The organising rule under extreme growth is that no team may block another — even when honouring it means adding to the very monolith you are trying to dismantle.

  1. Thuan Pham Uber's first Chief Technology Officer, from 2013 to 2020 the philosophy we all operate at the time was no one should be blocking anybody else. No one can block anybody else. Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com · 1 Apr 2026 · 0:51:45 into the videoAll korrents from this video
    Their wordsthe philosophy we all operate at the time was no one should be blocking anybody else. No one can block anybody else.

    Where this was said

    Watch from 0:51:45 plays here

    ↗Scaling Uber with Thuan Pham (Uber's first CTO)youtube.com

    1 Apr 2026 · video · 1h 39m · spoken · machine transcript

A viewour reading

A codebase too large for a model to hold has to be split, whatever it cost before

1 claim filed here, newest first — each in the words of whoever said it.

A company on a monolith cannot use AI on it: no model in the next eighteen months will hold that codebase, so the monolith has to be broken up or rewritten.

  1. Steve Yegge Software engineer of four decades who spent years at Amazon and Google If you're a monolith, you're kind of hosed because I told you the ceiling's going up for what they can do, but it ain't ever going to hit your monolith. They will never fit in the context window and you're never going to be able to never in the next 18 months be able to tell a model go fix my monolith. You have to break it up. From IDEs to AI Agents with Steve Yeggeyoutube.com · 11 Mar 2026 · 0:41:29 into the videoAll korrents from this video
    Their wordsIf you're a monolith, you're kind of hosed because I told you the ceiling's going up for what they can do, but it ain't ever going to hit your monolith. They will never fit in the context window and you're never going to be able to never in the next 18 months be able to tell a model go fix my monolith. You have to break it up.

    Where this was said

    Watch from 0:41:29 plays here

    ↗From IDEs to AI Agents with Steve Yeggeyoutube.com

    11 Mar 2026 · video · 1h 32m · spoken · machine transcript

On this topic, not yet placed

Matched by wording, not yet read into a view. The archive grows on its own, so this is where new claims wait for somebody to read them.

The full chronology, with every quote: software quality as a timeline · person by person, side by side · all topics · Something wrong? Tell us