Mastodawn

Really enjoying this interesting and challenging write up about software engineering as it is changing underneath us: https://apenwarr.ca/log/20260316

I'm not sure I'm fully bought into the conclusions, but I find the core idea of quality being better achieved through a differnet process quite compelling. At least as an idea. Anyways, you should read it and have your own thoughts.

Choice pull-quotes for me:
"""
Every time something goes wrong, you have to ask, “How did this happen?” and then do a whole post-mortem and the Five Whys (or however many Whys are in fashion nowadays) and fix the underlying Root Causes so that it doesn’t happen again. “The coder did it wrong” is never a root cause, only a symptom. Why was it possible for the coder to get it wrong?
"""

"""
Maybe we finally have a compelling enough excuse to fix the 20 years of problems hidden by code review culture, and replace it with a real culture of quality.

I think the optimists have half of the right idea. Reducing review stages, even to an uncomfortable degree, is going to be needed. But you can’t just reduce review stages without something to replace them. That way lies the Ford Pinto or any recent Boeing aircraft.
"""

"""
Every team has some monoliths that are a little too big, and too many layers of reviews. Maybe we won't get all the way to Singularity. But, we can engineer a much better world. Our problems are solvable.

It just takes trust.
"""

Every layer of review makes you 10x slower

We’ve all heard of those network effect laws: the value of a network goes up with the square of the number of members. Or the cost of commun...

Show thread

Billy O'Neal Mar 17

@chandlerc I'm sad seeing people constantly relearn what "[NSB][1]" taught us in the late 80s. The cost of translating the ideas into code going to 0 would not be a 10x productivity improvement because incidental complexity is not 90% of the problem. It's Amdahl's Law for code

[1]: https://en.wikipedia.org/wiki/No_Silver_Bullet

No Silver Bullet - Wikipedia

Show thread

Randy Smith Mar 17

@chandlerc If you're willing I'd value hearing your critiques/questions about the conclusions, just to have another narrative in my head in this space.

The major thing I took from it is how important trust is for productivity in organizations, and how much it costs when that is lost. But that's a major bias-confirming point for me (mutter mutter 11 years @ G***gle mutter mutter), so I should probably be careful about accepting it too blithely.

Do you disagree with that point? Or are there other conclusions you see him as drawing you disagree with?

Show thread

Chandler Carruth Mar 17

@curiouserrandy I definitely _agree_ with how essential trust is.

There may be some bias, but I have too many data points that back it up...

I'm not sure I disagree with anything in the article TBH, but the part I'm still thinking about before making up my mind is around code reviews being in essence a form of layered-QA that was shown to not actually achieve the desired quality in a manufacturing context. The historical lesson is pretty clear cut, but I have questions about whether the analogy applies effectively to software. But it is a really interesting challenge my assumptions about software and so something I'm continuing to ponder.

Show thread

Randy Smith Mar 17

@chandlerc that all makes sense.

Random speculation: I wonder if it's worthwhile separating out the "How many eyes look at a work product" from "Layers of review". I don't know anything about design/production in the physical assembly space, but I could easily imagine that it naturally involves multiple people. That might suggest substituting pair programming (+ trust + an emphasis on quality code) for the first layer of review, which might substitute a x2 cost for an x10 cost.

Again, pure speculation; I also have very little experience with pair programming. But what I do have suggests that just having a second pair of eyes and brain going through the process in parallel catches a lot of possible failure points.

Show thread

Chandler Carruth Mar 18

@curiouserrandy

Yeah, I am also thinking along similar lines.

The more I think about it recently, code review has ended up in an awkward place:
- Try to do optional code review, it just never happens
- Eventually, make it mandatory and pre-commit to ensure it happens
- Ooops, now it's not just a second set of eyes, it's a layer of review process to make progress

Pair programming I think neatly side-steps this doom loop, which in nice. But it has its own challenge due to its synchronous nature: timezones. This makes it incredibly difficult to insist on, especially in environments like open source projects.

What I want is an async code review process that _feels_ more like pair programming rather than a layer of review, and so doesn't explode to the 10x cost. But not sure how to achieve that (yet).