Too many of the same speakers at the same conferences.
Dragan Stepanović
@dstepanovic.bsky.social
Trying hard not to think about small batches, bottlenecks, and systems. In the meantime: XP, ToC, Lean, Systems Thinking.
Software delivery measurement vendors would like you to improve the metrics, but not to the point where you change the way of working (XP) to the point that you no longer need the vendor or the measurements.
The risk of doing great work in software development is that it can look like the team isn't trying as hard as the teams heroically fighting fires (that they started)
My daughter Beth's joke: make programmers "work to rule," so they must refactor, test, integrate, collaborate. As a strike it fails, because you'd get more productive. A part we stopped laughing at. Teams did it, shipped great software, and got fired anyway.
The Toyota Way isn’t just about small gains. At its heart? Kaizen.
The purpose of all automation and cost reduction we got as a result of technological improvement since the start of the Industrial Revolution was to spend more time on social networks and consuming polarizing and addictive content. The purpose of the system is what it does. (POSIWID).
The right time to intervene in systems where an exponential, reinforcing feedback loop is dominating the system's behavior is when it seems it's too soon. "Let's wait and see" is a guarantee that it'll be too late.
We used to say..."we cannot afford to wait and see on climate change." We did all sorts of teaching about the delays and momentum and how because of them, once it got bad it would be too late, and now it's bad but that presumed action that the bad would unlock, well...there were other forces....
“A numerical goal leads to distortion and faking, especially when the system is not capable of meeting the goal. Anybody will meet the quota (goal) allotted to him. He is not responsible for the losses so generated.” W E Deming, in “The New Economics”
The problem is that people deciding if developers should be writing code are very often the ones who have never had enough experience with writing code to have a good idea what the value of writing code is and the purpose it serves, but they are convinced they know.
The counterintuitive idea about managing flow is that the leverage is most often much less about speeding up slow parts and much more about slowing down parts that are running too fast when taking into account the whole system.
I've seen comments about accepting LLM-generated code in that we don't/can't understand it and excusing that because: "There's always code in the system that we don't understand"
Except, LLM-gen'd and human-written code are different. One was written by someone with a mental model. Modified by humans with another mental model (correct or not), etc. The other is generated by statistical, stochastic methods with constraints. These are not the same.
Slides from my talk "Agentic Coding - A Systems Perspective" or how not to inflate the elephant traveling through a boa constrictor. The talk combines Theory of Constraints, Systems Thinking, XP, and Lean lenses of agentic coding. drive.google.com/file/d/14YVq...
Agentic Coding - A Systems Perspective.pdf
drive.google.com
Does it ever hit home that the ascendancy of AI is taken to be assured, but the shifting of human society to fit into earth system limits is seen as everything from a head-scratcher to a longshot to an impossibility?
Effort one needs to put into reviewing plausible-looking code compared to code a teammate wrote is likely an order of magnitude higher per line of code, because it's plausible, and finding where that gap between plausible and right is feels like looking for a needle in a haystack.
I understand this just feels like "normal coding" to a lot of folks. But it runs directly against XP/Lean practices. It was waste.
"Saving planet Earth" is coming from a good place, but it's yet another clue exposing deeply ingrained belief system revolving around human exceptionalism. Planet will save itself regardless of humans. Reality doesn't care what we think of it, or what we think it should be. It just is.
Sometimes the tail also needs to wag the dog as the dog wags the tail, so the dog knows that it cannot wag the tail as much as it thinks it can.
It's not that the cost of code went to zero but that the cost of _plausible-looking code_ went to zero. It might've went to zero (hint: price hikes says not) but the surrounding costs in the process (cruft, complexity carrying costs, rework, etc.) went drastically up.
Any tooling that makes big changes easier or faster to review and/or deploy is still solving the wrong problem. Reality (production) doesn't care how long it took you to review a big batch or how difficult that was.
You can't escape Goodhart's Law Amazon scraps AI leaderboard to stop workers chasing usage scores - www.ft.com/content/b1a6... via @FT
Amazon scraps AI leaderboard to stop workers chasing usage scores
Senior executive Dave Treadwell tells staff ‘don’t use AI just for the sake of using AI’ as costs rise
ft.com
Every morning I wake up, sit at the computer, pull up Claude and ask it: "Where's my favorite next plausible token predictor?" and it just blushes back at me.
Mistaking the Output for the Process open.substack.com/pub/draganst...
Mistaking the Output for the Process
One of the typical examples of mistaking the output for the process that I see nowadays with adding “guardrails” in agentic coding is the idea that you can somehow assess code quality mostly by lookin...
open.substack.com
"The problems the world faces today are not caused by our inability to achieve our goals—they are a direct result of our success. They are a result of how destructive we are in the pursuit of our goals." consilienceproject.org/development-...
Development in Progress - The Consilience Project
consilienceproject.org