@Patricia
I've read your blogpost: you're absolutely right. It matches exactly my observations.

I never wanted to build UIs. Nobody else liked it either and their output was unsellable. So I ended up doing UI on top of my *real* job in almost my entire career.

There is *one* thing that I've learned quite early: figure out the customer's *real* painpoints (you won't find them in any written material). You need to speak with them over and over again, and you need to discern *your own* pets from *user needs* and be willing to let go.

TL;DR: it's the art of never-ending careful listening to your users that makes you successful. The rest is craftmanship, automation, knowledge.

Thanks for writing this, @Patricia. Funny enough I have been pondering and experimenting this for years now too and I’m hoping to put my thoughts down on this in the next months and once I have, I’d love to hear your take. 🙂

For now, I can share my core thoughts:

1. Software is the only engineering discipline that has not been industrialised
2. If I think of building a platform product (like Spotify), I think of Disney World
3. I believe we lack clarity in the orchestration level that bridges…

@Patricia

I was thinking that the focus on reducing and eliminating waste is one of the better and more general and useful concepts that come over from Lean (manufacturing and/or design). Sure, we're not wasting material supplies in software development, because RAM and disk storage are practically perfectly recyclable.

But we waste TIME.

And, in design, *time* is (most often) our most precious resource.

Human time, and even CPU time, disk space, network bandwidth and other such resources.

@worldwidewerner @Patricia I’ve been broadly nodding along with this thread, but there does seem to be a misunderstanding here.

In TPS, waste was “muda” which I think is possibly better translated as “excess”, which in turn meant “anything that increases the overheads or lowers the output of the factory”.

Lean (confusingly) means something considerably different by “waste”. It means “anything that does not add value for the customer.”

I hate that phrasing, but I get what they mean to say. It’s about any effort spent that does not result in software that does its job better (which can include changing that job when you _understand_ it better). It’s about waste in the process, not the product.

One of the problems with Lean is it misses or de-emphasises important dimensions of that aim. This list (https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) is pretty much entirely about things you would intuitively think about as “a waste of my time”. That’s what happens when you take an idea that’s primarily about elegance and you forcibly mash it into minds that have been taught to think in terms of time and motion.

I don’t recommend people follow any methodology religiously. I do find Lean a useful lens to look at software through. Even considering the things it misses, I have encountered each of those “wastes” far, far too many times. And they’re worth harping on about because people are — weirdly — resistant to fixing them, perhaps because they can’t see the cumulative impact.

(The one exception would possibly be “partially done work”, because sometimes that’s a good thing. That sometimes means you worked out you were doing the wrong thing and stopped. Better late than never!)

(Aaand this should’ve been a blogpost, sorry)

@syklemil @exception as I said here (quoted), but also it is everywhere even if you don’t know that’s where it comes from. Kanban, all the talk about Waste, measuring the time a task is «in progress», so many things that people think are «agile» come from this misunderstanding.

https://social.vivaldi.net/@Patricia/114580703866929875