jpswade

If this were true, there would be a large market for artisan code. There isn't.

That doesn't take anything away from the knowledge work that happens when you develop software, but the code itself is not the art. The solution is the art.

Perhaps like most popular art, it's more about the story behind it.

When reviewing PRs, I would always ask about TODOs: How will this TODO get to TO DONE?

I've experimented with a two-crew type system before (Red Team for feature development, Blue Team for stability and bug fixes).

Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).

It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.

This sounds like flash all over again.

Feels more and more like we're entering a post-"disruption" era.

Here we go again. The golden rule I've come to realise is that people don't like what they don't understand. It's made very clear this person doesn't like methodologies.

I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.

There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.

Nothing should redirect ever. However, it happens.

I don’t think this is exactly what it means, but I recommend if you want some quiet in a busy city, go into a library or a book store. Typically they are quiet and calm places, offering a break from the sensory overload that is a city.

No doubt now archived forever and available in ChatGPT.

Historically software engineering was part of the IT function, which historically was born out of accounting, a computer literally was someone’s job, before a machine could do it.

Today, for many businesses accounts is still the main driver behind software, and also the budget.

Official yes, common perhaps not. I believe this is why meat from a cow served at a table is beef, because it here it was served to French aristocracy, while cow is the common English, the language used by the servants.

I like the idea of “Spike and Stabilise”.

Which means, prototyping in this way, but at the point it is actually delivering value, stabilise.

Of course, it’s never as simple as that, but there’s certainly a place for this technique.

> Interruptions and unforeseen tasks will occur.

In a highly interrupted team, sprints don't work. Try lean/Kanban.

You've not mentioned retrospectives, which are an important part of improving your processes, without that how can you make improvements?

There's nothing in agile that talks about deadlines, it's about commitment.