Allen Holub
@allenholub.bsky.social
Author, international speaker, consultant, software architect, kitchen-sink wrangler.
A "metric," by definition, is a measurement. Empathy is a quality, not a measurement. "I'd like 10 pounds of your finest Empathy" doesn't make sense precisely because you cannot measure it. Similarly, feedback is a process, not a metric. I understand English. I'd suggest you buy a good dictionary.
February 11, 2026 at 6:48 AM
A "metric," by definition, is a measurement. Empathy is a quality, not a measurement. "I'd like 10 pounds of your finest Empathy" doesn't make sense precisely because you cannot measure it. Similarly, feedback is a process, not a metric. I understand English. I'd suggest you buy a good dictionary.
What? An MVP is a test of a product idea's viability, usually a small program. It's not a metric by any definition. There are no numbers involved. An MVP is an essential first step in product discovery because it puts something in your customers' hands so you can gather feedback and improve.
February 11, 2026 at 6:43 AM
What? An MVP is a test of a product idea's viability, usually a small program. It's not a metric by any definition. There are no numbers involved. An MVP is an essential first step in product discovery because it puts something in your customers' hands so you can gather feedback and improve.
You're clearly working with the wrong engineers!
February 10, 2026 at 3:59 AM
You're clearly working with the wrong engineers!
How would you do that, exactly? I can think of second-order metrics for satisfaction: Profit, for example, and subscription renewal rates, but those are all lagging, don't pinpoint what's right, and obscure what's wrong.
February 10, 2026 at 3:59 AM
How would you do that, exactly? I can think of second-order metrics for satisfaction: Profit, for example, and subscription renewal rates, but those are all lagging, don't pinpoint what's right, and obscure what's wrong.
I think, when used carefully, they can substantiate information that you acquire in other ways—through conversations, for example. Put another way, I don't think they drive the process. Caring about the customer drives the process.
February 10, 2026 at 3:56 AM
I think, when used carefully, they can substantiate information that you acquire in other ways—through conversations, for example. Put another way, I don't think they drive the process. Caring about the customer drives the process.
By working on the software one small problem at a time, we guarantee that every release does something useful.
People who say user stories are dead never understood what they were to begin with. You cannot build software without them.
5/5
People who say user stories are dead never understood what they were to begin with. You cannot build software without them.
5/5
February 9, 2026 at 9:04 PM
By working on the software one small problem at a time, we guarantee that every release does something useful.
People who say user stories are dead never understood what they were to begin with. You cannot build software without them.
5/5
People who say user stories are dead never understood what they were to begin with. You cannot build software without them.
5/5
A story describes our users' work, not ours.
The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful.
4/5
The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful.
4/5
February 9, 2026 at 9:04 PM
A story describes our users' work, not ours.
The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful.
4/5
The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful.
4/5
It cannot be estimated. It's the topic of conversation that we have with our users/customers to understand their problems and collaboratively develop the smallest, best solution. The story is not the solution—it's the beginning of the conversation you have to arrive at the solution.
3/5
3/5
February 9, 2026 at 9:04 PM
It cannot be estimated. It's the topic of conversation that we have with our users/customers to understand their problems and collaboratively develop the smallest, best solution. The story is not the solution—it's the beginning of the conversation you have to arrive at the solution.
3/5
3/5
The fact that the term has been corrupted by the Jira-slinging ticket-money pseudo-Agile Scrummy culture is a real shame, because it's a valuable concept:
A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification.
2/5
A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification.
2/5
February 9, 2026 at 9:04 PM
The fact that the term has been corrupted by the Jira-slinging ticket-money pseudo-Agile Scrummy culture is a real shame, because it's a valuable concept:
A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification.
2/5
A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification.
2/5
A user story is not a code word for specification or a requirement or any description of work. It is not a ticket. It is not a to-do item. It is not something you can build.
1/5
1/5
February 9, 2026 at 9:04 PM
A user story is not a code word for specification or a requirement or any description of work. It is not a ticket. It is not a to-do item. It is not something you can build.
1/5
1/5
I need a title I can use for classes. "AI" has sucked the air out of the room, but AI-architecture is, ultimately, just architecture. I want to get across the notion that I'm teaching both.
February 9, 2026 at 8:17 PM
I need a title I can use for classes. "AI" has sucked the air out of the room, but AI-architecture is, ultimately, just architecture. I want to get across the notion that I'm teaching both.
But does lowering the software's quality increase profits? My experience is that writing low-quality code takes longer.
February 9, 2026 at 7:39 PM
But does lowering the software's quality increase profits? My experience is that writing low-quality code takes longer.
I think not only will it not help them, but they can't really use AI effectively without this stuff. Things like good architecture become more important the more you use the AI. Somebody who knows nothing but AI-assisted coding will soon become unemployable.
February 9, 2026 at 7:31 PM
I think not only will it not help them, but they can't really use AI effectively without this stuff. Things like good architecture become more important the more you use the AI. Somebody who knows nothing but AI-assisted coding will soon become unemployable.
I want to "AI" thrown in there somewhere 😄
February 9, 2026 at 7:15 PM
I want to "AI" thrown in there somewhere 😄
The problem is that I use "pairing" in the pair-programming sense, and that kind of pairing is part of the larger process.
February 9, 2026 at 7:14 PM
The problem is that I use "pairing" in the pair-programming sense, and that kind of pairing is part of the larger process.
It addresses denigrating approaches that do not amplify the status quo, which you are doing. Your status quo is estimation. My reality is clearly different from yours, because I've done what I talk about many times, and many of my clients have done it, and nobody's missed the estimates.
February 9, 2026 at 7:13 PM
It addresses denigrating approaches that do not amplify the status quo, which you are doing. Your status quo is estimation. My reality is clearly different from yours, because I've done what I talk about many times, and many of my clients have done it, and nobody's missed the estimates.
I've been using the term "AI-assisted software engineering" as a counter to "vibe coding," which I see as something else entirely. The term itself is a mouthful, though. Can anybody recommend something more pithy?
February 9, 2026 at 7:11 PM
I've been using the term "AI-assisted software engineering" as a counter to "vibe coding," which I see as something else entirely. The term itself is a mouthful, though. Can anybody recommend something more pithy?
<sigh /> See: Larman's Law.
February 9, 2026 at 6:54 PM
<sigh /> See: Larman's Law.
And your guess would be wrong.
Customers expect you to solve their problem, share a common strategic goal, and make progress towards that goal. They don't need a roadmap to failure. They need to observe progress through frequent releases that lead to necessary changes early, when they're cheap.
Customers expect you to solve their problem, share a common strategic goal, and make progress towards that goal. They don't need a roadmap to failure. They need to observe progress through frequent releases that lead to necessary changes early, when they're cheap.
February 9, 2026 at 6:39 PM
And your guess would be wrong.
Customers expect you to solve their problem, share a common strategic goal, and make progress towards that goal. They don't need a roadmap to failure. They need to observe progress through frequent releases that lead to necessary changes early, when they're cheap.
Customers expect you to solve their problem, share a common strategic goal, and make progress towards that goal. They don't need a roadmap to failure. They need to observe progress through frequent releases that lead to necessary changes early, when they're cheap.
No metric improves product decisions. You do that by talking to your customers.
What does improve product decisions is empathy, feedback, and understanding the market.
What does improve product decisions is empathy, feedback, and understanding the market.
February 9, 2026 at 6:39 PM
No metric improves product decisions. You do that by talking to your customers.
What does improve product decisions is empathy, feedback, and understanding the market.
What does improve product decisions is empathy, feedback, and understanding the market.
I've seen it work, however. Not sure where your confidence comes from, but my guess is that it's a small sample.
February 9, 2026 at 6:22 PM
I've seen it work, however. Not sure where your confidence comes from, but my guess is that it's a small sample.
Complicated code is impossible to change. Why waste time writing code that you don't need?
9/9
9/9
February 9, 2026 at 6:04 PM
Complicated code is impossible to change. Why waste time writing code that you don't need?
9/9
9/9
Writing a component system take no more effort than writing a disorganized blob of code. The cost is zero.
It does mean that you have exactly as much code as you need to solve the problems at hand. Not one semicolon more. No futureproofing. No just-in-case's. Simple code is easy to augment.
8/9
It does mean that you have exactly as much code as you need to solve the problems at hand. Not one semicolon more. No futureproofing. No just-in-case's. Simple code is easy to augment.
8/9
February 9, 2026 at 6:04 PM
Writing a component system take no more effort than writing a disorganized blob of code. The cost is zero.
It does mean that you have exactly as much code as you need to solve the problems at hand. Not one semicolon more. No futureproofing. No just-in-case's. Simple code is easy to augment.
8/9
It does mean that you have exactly as much code as you need to solve the problems at hand. Not one semicolon more. No futureproofing. No just-in-case's. Simple code is easy to augment.
8/9
This is, again, critical in an AI context. A system make of small components with impermeable boundries easily contains problems that an AI might create; it's easy to test as black boxes without having to fully understand; it gives you a very small "blast radius" if something goes wrong.
7/9
7/9
February 9, 2026 at 6:04 PM
This is, again, critical in an AI context. A system make of small components with impermeable boundries easily contains problems that an AI might create; it's easy to test as black boxes without having to fully understand; it gives you a very small "blast radius" if something goes wrong.
7/9
7/9
Code goes together faster when you write the tests first (even/especially if you're using an AI assist—tests make great specifications).
It does mean that you have exactly as much architecture as you need. It helps if that architecture can grow incrementally, but that's not hard to acomplish.
6/9
It does mean that you have exactly as much architecture as you need. It helps if that architecture can grow incrementally, but that's not hard to acomplish.
6/9
February 9, 2026 at 6:04 PM
Code goes together faster when you write the tests first (even/especially if you're using an AI assist—tests make great specifications).
It does mean that you have exactly as much architecture as you need. It helps if that architecture can grow incrementally, but that's not hard to acomplish.
6/9
It does mean that you have exactly as much architecture as you need. It helps if that architecture can grow incrementally, but that's not hard to acomplish.
6/9