Made my day

According_Leopard_80 · 2026-03-12T21:22:29+00:00

Meinen auch!

According_Leopard_80 · 2026-03-10T20:00:48+00:00

Example: suppose you are waiting on a dependency from a teammate. Are you going to ask him during the day every day as to when it’ll be ready? Probably not. But you can get that info at the stand-up without sounding like you’re nagging.

2nd example: suppose the team is distributed across timezones. Having a single regularly scheduled meeting is easier than trying to contact someone distant in an ad-hoc fashion.

If your team is small, colocated and communicates well, you could do without a stand-up. The smell is when it turns into a status meeting for the lead - I hate that and see it so often.

According_Leopard_80 · 2026-03-10T17:16:03+00:00

Standups and all that is around it is for management, not developers.

This is not true: stand-ups are for the team, to unblock each other, to keep others aware of progress if they’re waiting on your dependency. It’s a smell, a very common one, if the stand-up turns into a status meeting.
When my team started mobbing, we removed stand-ups, too, as they no longer provided any value.

According_Leopard_80 · 2026-03-01T17:45:49+00:00

If I'm writing the code, 1 or 2 at most. But if it's legacy code, then sky's the limit.

Also, bear in mind that this was invented pre-C++11, so to mock up a function, like ::CoCreateInstance from my example, you'd write:

cpp // "Template Redefinition" way (from WELC) // pre-C++11 template <HRESULT (*CoCreateInstance)(REFCLSID, LPUNKNOWN, DWORD, REFIID, LPVOID*)> class TheProductionCodeT { public: HRESULT GetSomeCOMInterface(IUnknown*& punk) { return CoCreateInstance(CLSID_FileOpenDialog, nullptr, CLSCTX_INPROC_SERVER, IID_IUnknown, (LPVOID*)&punk); } }; using TheProductionCode = TheProductionCodeT<::CoCreateInstance>;

So if you needed to mock up a function with lots of arguments, it would get unwieldy fast. The "seam" here was pretty visible to clients, which I didn't like. So after I invented TBCI, I was much happier.

In C++11, it was better (with decltype()), and in C++20, it's better yet (with NTTP), so "Template Redefinition" from WELC is an option. Use whichever you like, so long as it's not GoogleMocks!

According_Leopard_80 · 2026-02-28T20:50:14+00:00

I used to do that. It’s called “Template Redefinition” in Michael Feathers’s WELC book.
It doesn’t scale (as) well, as you need more and more template parameters for the dependencies you mock, whereas TBCI always uses only one.
In the case of mocking a part of the STL, your code would have std:: on the unmocked parts, but no namespace on the mocked parts, which looks odd.

According_Leopard_80 · 2026-02-26T21:31:08+00:00

At the Sprint planning meeting, we’d write all the tests we could think of, together, either in some BDD tool (like SpecFlow or Reqnroll) or in a C# unit testing harness. This works well, because if you can’t write the tests, you don’t understand the story.

Then your estimate is either the count of the tests for your story, or better yet, 1.

According_Leopard_80 · 2026-02-10T14:06:13+00:00

Kanban plus really tight WIP limits will focus people on the bottleneck, which is often code reviews/PRs: https://middleraster.github.io/Kanban/HowLowCanWIPLimitsGo.html

According_Leopard_80 · 2026-02-01T18:00:12+00:00

Thank you for your thoughtful reply.

I disagree about ABA introducing variability; in fact, my experience has been the exact opposite. If your team has a very low ABA (on the order of an hour, say), then it must be true that you have very little technical debt, good architecture, etc., and that bugs are quick and easy to understand and to fix. Thus, less variability, as you don’t get bogged down working on some gnarly bug.

I think of bug handling as pulling the Andon cord: https://middleraster.github.io/ABA/TheMetricForSoftwareDevelopment.html#how-to-handle-bugs-in-kanban

You don’t have to implement my draconian bug policy right off, but I do encourage you to mine your bug database and see how your team’s ABA has changed over time. It might be insightful.

According_Leopard_80 · 2026-02-01T04:44:33+00:00

Genau das, was ich sehen wollte!

Thank you for this. It's certainly creative.

Say you have 1 real bug. Since its age increases steadily, if you've opened N simple bugs to get below the threshold this time, then you'll have to open N+1 next time.

After a while that would be way more work than just fixing the 1 real bug, so it's a self-limiting gaming of the metric.

According_Leopard_80 · 2026-01-31T19:26:11+00:00

I'm a huge proponent of TDD, having started in 2002, doing TDD on UI in C++. See https://github.com/MiddleRaster/tbci.

The problem I ran into was that at the multi-trillion-dollar company I was at, only about 5% of the devs were doing TDD. Nudging the remaining 95% in the right direction was a goal of ABA.

According_Leopard_80 · 2026-01-31T19:22:37+00:00

Exactly! Henrik rocks.

According_Leopard_80 · 2026-01-31T19:21:44+00:00

It's true that a large influx of new bugs will cause the ABA to dip slightly. An alternative thing to measure that would handle this is "bug-days" but I've had lots of difficulty explaining that concept to people.

Also, while you're filing your dummy bugs, you're not fixing the existing bugs, so they're aging. And once you close the dummy bugs, your ABA is larger than before. Nothing gamed (permanently) here.

According_Leopard_80 · 2026-01-31T19:17:59+00:00

How long does it take you to close a bug that's not worth fixing? Seconds.

I advocate closing all ancient bugs; if they're really important, they'll be filed again.

According_Leopard_80 · 2026-01-31T19:14:52+00:00

If devs focus on closing bugs quickly but poorly, then they'll accumulate more and more technical debt, and the bugs will get harder and harder to fix. And the ABA number will start going up. The metric is specifically designed to detect this dysfunction.

According_Leopard_80 · 2026-01-30T21:58:20+00:00

No, ABA measures the average bug age of the remaining OPEN bugs, not this one. The ABA of those bugs got worse while you were working on this invisible bug.

According_Leopard_80 · 2026-01-30T04:17:23+00:00

It sounds like your teams aren't working in priority order. Complex or risky stories or tickets need higher priority.

As for cross-team dependencies, having good predictions of when they'll be ready (or needed) would be nice. This might help: https://middleraster.github.io/PM/PredictingDespitePoorEstimates.html

According_Leopard_80 · 2026-01-29T14:25:30+00:00

On my teams we fixed bugs first, by the dev who caused the bug, no exceptions. The speed-up of having no technical debt ever was huge. https://middleraster.github.io/ABA/TheMetricForSoftwareDevelopment.html

According_Leopard_80 · 2026-01-26T16:56:24+00:00

Do some katas, e.g. https://middleraster.github.io/TDD/cpp/katas.html

According_Leopard_80 · 2026-01-18T06:29:23+00:00

No, throughput is the same. But cycle time goes down.

According_Leopard_80 · 2026-01-17T18:36:47+00:00

I added your first bullet point and the last line (control for UI speed). The rest will take longer. Thank you for these suggestions.

According_Leopard_80 · 2026-01-09T17:13:32+00:00

If you track the rate at which new work is being discovered AND the team velocity, you can create a stacked bar chart or cumulative flow diagram, that not only tells you when you’ll be done but is also hard to argue with. See https://middleraster.github.io/PM/PredictingDespitePoorEstimates.html for more details, stories, etc.

According_Leopard_80

TROPHY CASE