korrents

korrents · learn · software-engineering

Programming and software engineering

7 open questions

Start here

Programmers argue in public about types, tests, abstractions and where code runs; learn where they part.

Ours, not the speakers'.

Where the field disagrees

How to read this part.

Each question below is one the field is arguing about now. Under it are the views, one sentence each, in our words, and the people whose dated claims sit under each one, in theirs. Learn the arguments before the answers: being able to say why two serious people disagree is most of understanding a field. Nobody is filed under a view; their claims are, so somebody can appear under two. Tap a view to check it against the exact words.

What do coding agents change about software work?

All agree the tools got good; they split on what that changes and what a person is still for.

  1. The gain is large, and it goes to whoever works with the agent directly

    David Heinemeier HanssonThomas PtacekBoris Cherny

  2. Writing the code was never the binding constraint, so making it cheap changes less than it looks

    David Heinemeier HanssonSunil Pai

  3. The person who checks the work is a safety property, and removing them is the risk

    Mario ZechnerSimon Willison

  4. What an agent should be given to work with is still being argued out

    David Heinemeier HanssonTobias LütkeSimon WillisonPeter Steinberger

9 voices · 20 claims · 2 changed their mind · read the whole argument

Do static types make software better?

They split on whether types prevent bugs, or mostly buy better tools, and on how strict they should be.

  1. Types pay for themselves, mostly through the tools that can be built on them

    Guillermo RauchKelsey HightowerAlice RyhlAnders HejlsbergDillon Mulroy

  2. The evidence that types prevent bugs is thin, and dynamic languages ship fine

    David Heinemeier HanssonDan Luu

  3. The best types are the ones you can add gradually or let the compiler infer

    Anders HejlsbergJamie BrandonAllan Odgaard

  4. If you are going to have types, have the strictest kind

    Jamie BrandonTim SweeneyDillon Mulroy

11 voices · 19 claims · read the whole argument

What are tests for, and how much testing is enough?

They agree tests buy confidence and split on which tests, how many, and whether agents change the answer.

  1. Tests should exercise the software the way it is used, not its insides

    Kun ChenYihui XieKent C. DoddsHillel Wayne

  2. Coverage is the wrong target: a high number says little about how good the tests are

    Salvatore SanfilippoMarc LittlemoreThorsten BallMartin Fowler

  3. Test-driven development is a tool for some kinds of work, never a test of professionalism

    Kent BeckHillel WayneAllan Odgaard

  4. Coding agents make tests matter more than they ever did

    Kent BeckMartin FowlerSimon WillisonGeorge Hotz

  5. Tests an agent wrote cannot be trusted on their own, so a person still has to check

    Peter SteinbergerDex HorthyTony FadellMario Zechner

16 voices · 26 claims · read the whole argument

When does an abstraction help, and when does it hurt?

They argue over when to share code, whether the classic clean-code rules help, and what hiding the details costs.

  1. Duplication is cheaper than the wrong abstraction, so wait for real examples before sharing code

    Peter SteinbergerTobias LütkeSandi MetzCasey Muratori

  2. The rules taught as clean code make programs worse, and slower

    Casey Muratori

  3. Every abstraction leaks, so somebody has to know the layer below it

    Martin KleppmannFlora GuoNaval RavikantPhil Hagelberg

  4. A higher level of abstraction moves the difficulty somewhere else; it does not remove it

    François CholletAddy Osmani

11 voices · 17 claims · read the whole argument

Should software be one program or many small services?

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

  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

5 voices · 10 claims · read the whole argument

Rent the cloud or own the servers?

They argue over what the cloud really saves, and where the next wave of software will run.

  1. The cloud is neither easier nor cheaper, and owned hardware is not more work

    David Heinemeier Hansson

  2. The cloud's basic units are the wrong shape, and more layers on top cannot fix that

    David Crawshaw

  3. Agents and AI will run in the cloud first, not on your own machine

    M.G. SieglerPieter Levels

  4. What runs your software, and your AI, should be hardware you own

    Meng ToDavid Heinemeier HanssonGeorge Hotz

7 voices · 14 claims · read the whole argument

Why is it harder to simplify than to add?

Most here say simplicity is subtraction; they part over why it is hard, and when less becomes too little.

  1. Simplicity is subtraction: find the essence and cut everything else

    Evil RabbitSusan KareCharlie DeetsJosh PuckettSebastiaan de WithGreg McKeownand 3 more

  2. Simple is hard: it takes more thought and time than complex, and complex is rewarded more

    Jason YuanLoredana CrisanDavid Heinemeier HanssonFrank ChimeroRich HickeyPaul Grahamand 3 more

  3. The hard part is saying no: every addition is easy to justify, and products bloat unless someone cuts

    Peter SellisMike KriegerEvil RabbitGuillermo RauchJohn BaiJason Yuanand 4 more

  4. When building is cheap, editing becomes the scarce skill, and models pull the other way

    Nev FlynnCharlie DeetsDavid Heinemeier HanssonJason YuanLoredana CrisanKatarina Batinaand 1 more

  5. Less is not the goal: the aim is clarity, and cutting too far loses what mattered

    Charlie DeetsJason YuanJosh PuckettDylan FieldJulie ZhuoRaph Kosterand 6 more

31 voices · 60 claims · read the whole argument

Who to read first

The voices we picked out on these 7 questions, then anyone else on record about several of them. The number is how many of the questions they are on, not a ranking of who is right.

Who changed their mind

What moved somebody is usually what the argument turns on. Newest first.

  1. David Heinemeier Hansson ·

    No longer holdsThe ideas in software originate with humans; agents build what people tell them to build.

    I thought all the ideas would originate with the humans. They would tell their agents what to build, and off they went.

    On What do coding agents change about software work?

  2. Pieter Levels ·

    No longer holdsClaude Code is the coding agent to build with.

    I won't use SnekAI but I'll probably switch to @xAI soon

    On What do coding agents change about software work?

Ways of thinking this field uses

Mental models that keep turning up in these arguments. Our pick; each page holds the claims behind it, in the words of whoever said them.

The shape of the field

  1. 1968

    Go To Statement Considered Harmful

    Edsger W. Dijkstra

    A one-page letter arguing that jumping anywhere in a program makes it impossible to reason about. The start of structured programming.

  2. 1968

    How Do Committees Invent?

    Melvin E. Conway

    Systems end up shaped like the organisations that build them: the observation now called Conway's law.

  3. 1970

    Managing the Development of Large Software Systems

    Winston W. Royce

    The paper the step-by-step "waterfall" process is named after, though it warns against doing it in one pass.

  4. 1972

    On the Criteria To Be Used in Decomposing Systems into Modules

    David L. Parnas

    Split a program by the decisions likely to change, and hide each behind an interface. Where information hiding comes from.

  5. 1974

    Structured Programming with go to Statements

    Donald E. Knuth

    A careful reply to the go-to debate, and the source of the line about premature optimisation.

  6. 1978

    Time, Clocks, and the Ordering of Events in a Distributed System

    Leslie Lamport

    Machines on a network cannot agree on what happened first without care; this is how to order events anyway.

  7. 1984

    Reflections on Trusting Trust

    Ken Thompson

    A compiler can hide a back door that appears in no source code, so you can only trust code you built from the ground up.

  8. 1986

    No Silver Bullet: Essence and Accident in Software Engineering

    Frederick P. Brooks Jr.

    Most of the difficulty of software is in the problem itself, so no single tool will make building it ten times easier.

  9. 1991

    Lisp: Good News, Bad News, How to Win Big

    Richard P. Gabriel

    The "worse is better" essay: simple, slightly wrong software spreads faster than complete, correct software.

  10. 2006

    Out of the Tar Pit

    Ben Moseley & Peter Marks

    Most complexity in software comes from state, and most of it is accidental rather than required by the problem.

None of these 10 papers is in this archive yet. They are here so the page has the field's shape, not just its arguments: each carries no quote, no link and no claim beyond its title, authors and year, and the one-line notes are ours, about what the paper did rather than what anyone believes.

Where to go next