One of Kent Beck’s many great things to consider is this little mind-bender of a quote

for each desired change, make the change easy (warning: this may be hard), then make the easy change

The quote is on X but I first read it in his great little book Tidy First?. Yes, the question mark should be in there. Read the book for more.

Ok. This quote forces you to think for awhile, but is very good practical advise for any software developer I wanted to relate a story from last week where I used it.

Re-posted from Umain.

As I entered the office I found a seat next to a nice coworker in the quiet corner. Perfect!

Only thing… that screen didn’t have a USB-C cable. No worries I’ll run down to the IT department and nick one.

Only thing… once I got back up I realized that the screen didn’t even have a power cable. Back down to IT, but this time I checked and yes - there were missing extension cords too. So I asked for that.

Once back at my desk I now had to unplug (and UNTANGLE) the cords, so that I could plug in the other 3 desks, interrupting my coworkers flow 2 times. And then connect my own desk to power.

Now I could attach the power cord. And then the USB-C. And then connect my computer so that I could … what was I doing now again.

Over and over I see that in the paradigm shift we are in now, the good old practices keep resurfacing. For example: doing BDD and TDD turns out to be a good idea even if the code is written much faster—and often not by you. Or having a solid understanding of how to create a good, well‑structured engineered application is more important now than ever.

There are more things, but I’ll get to that at the end.

In this post I wanted to share some thoughts about lead time that I cannot get out of my head. Let’s go back to the beginning by me sharing the simplest diagram I can think of, presented here in my handwriting from 2018, first shown in a blog post on flow efficiency.

A long time ago I wrote a blog post on TCR, just now it came up again. I showed them the old blog post but realized that it was very outdated and wanted to update it to a modern stack.

Read the original post to understand what this about. You can find my code here

The new craze in AI world is called Specification-Driven Development (SDD) and pioneered by GitHub SpecKit and probably other that I haven’t heard about yet.

It tries to solve the thing that many of us found troublesome with VibeCoding Dave Farley breaks this down here and instruct the AI on a lower level, taking more control of the details.

And it’s quite impressive, from what I’ve seen. Especially considering that it has a good what about existing code but it misses the mark on two fundamental assumptions I think.

With the risk of this post being out-dated before the end of the day, and me being branded Old guy that just don't get it - let me offer my thoughts on these two assumptions.

In my last post, I complained about my (and others’) flow being disrupted by institutionalized blockages — in that case, pull requests (PRs).

Often, when that happens, there are things you can do to improve the situation.

For example, let’s say (because it was the case) that I had to wait for an approved PR before I could test something — a GitHub Workflow, for instance. The workflow needed to be approved and merged into main before I could run it in GitHub Actions.

Now imagine that I waited for approval, only to discover — over the weekend, when I was off — that my fix was wrong. I’d need to make a tiny change and then wait for approval all over again. Annoying, right?

Being someone who cares about flow, I wanted something better. What could I do so that, once my code was ready to...

I’ve been writing some code this week. Well, I do most weeks, but this week I teamed up with some folks here at work. It was great fun — and actually did something pretty useful.

What struck me, though, were the blockages in the process. Some of them was even built-in. That kind of slowness was frustrating, and I think it could have been avoided.

I was lucky to work alongside Lars Albertsson, learning from his vast experience at a few of the top software companies in the world. One phrase Lars kept repeating stuck with me as we set up and refined processes at Scling:

Flow is sacred. Do not disturb the flow.

This simple mantra carries profound implications. Not just for you.

Yes. Me too. I felt that had to write something about AI and how it affects our professions (I consider myself a software developer, agile coach and product development person for the scope of this article).

Because reading about AI, and it’s application in digital product development, is very scary since some reports makes it feel like our entire profession is gone in 2-3 years (not true, but hecka-scary as big companies are laying off developers en masse). While others are more in camp “this is a fad and will soon all pass” (not true either, me thinks).

I do think that generative AI is a paradigm shift, but just as with others that I’ve experienced (Internet, Open Source, Agile, Cloud, Serverless and DevOps to mention a few) it is hard to know where it will take us, how it will change us before the dust has settled.

I stay...

Just back from a four-week vacation (out of the 5 weeks mandated by law in Sweden, btw. Sweden is great!) and as always this downtime has led to some reflection on my part. What I am about to write about, might just be me, but I found this useful and stress-relieving. maybe you do to.

We ended up in a cabin out in the archipelago that had spotty network access, only landline TV and our kids were at camps or with friends. Yes, we went directly into retirement. We set the clock to remind us about the TV-show that started 21.30.

[UPDATE] I totally forgot but a technical glitch happened that took away data traffic from my phone for about 4 days. That … reset … was very blissful and totally helped me make this transition and look at things differently.

What I noticed was how twitchy my fingers...

In this presentation, my great inspiration David L. Marquet, drops a quote that I somehow hadn’t heard before:

[When changing our ways of working] we act our way to new thinking, rather than think our way into new ways of acting.

This aligns well with many lean and Toyota Production System (TPS) principles. Toyota kata by Mike Rother shows how this practice is used extensively throughout Toyota.

I just had a mini-experience of this, where I wanted to document a pretty unwieldy conversation that was touching highs and lows in a large-ish writing undertaking we’re doing at work. Rather than start, because I didn’t know where, I thought about the best approach.

In my mind, each idea for how to approach this task, was presented and discarded. Then I just went ahead and did it. I opened a place where we had previously written parts of...