I agree. At least where we should be heading at some point of "professional maturity". I think many people though stop at blaming the user instead of trying to understand and guide, because it's just really hard and frustrating work :) And the payoff is not immediate or obvious.

Yeah, exactly. So not doing it explains why so much software totally sucks, especially B2B.
Every job looks so easy... until you actually do it and understand what it really looks like ;) Then those "users never know what they want" and "always complain" turn out to not be true ;)

For some, it may be a horror, for others, maybe some calm after months or years of hearing "AI taking your job" nonsense ;)

Doctorow - if somebody has much bigger wallet than you, then voting with your wallet doesn't look like such a smart idea; some things can be only changed by policy and hoping to influence them by individual actions and choices is doomed to fail.

That conversation didn't dissappoint, especially on points where there was some disagreement between the panelists :)
My key takeaways: Zitron - many "useful AI" examples are not really LLMs, or where there before the current wave of hype, they're the "old school, different kind of AI" rebranded.

Or even more, the real power of DDD is two things: the pace of change in (most) businesses is so much slower in tech and the cost of it is so much higher.
So the better your design is aligned to what's stable in that domain, the easier it is to deal with the changes that are inevitable.

Some changes seem disruptive - like the regulation in short-term rentals (AirBnB etc) or DAC7, but that's something that was discussed 10+ years ago in that industry at meetups, conferences, etc.
To me, this is the real power of DDD: the pace of change in business is so much slower than in tech.

e.g. in the flat rental space we got COVID, then the war in the Ukraine, changing tenants preferences, big inflation, dramatically raising costs, but it's the same fundamentals - how much margin do you have? how high recurring costs? how long can you survive in bad times? how quickly you adapt?

Still if you look at the fundamentals, things don't change that often. The pace of change in software and tech is very fast, but the more established and mature the industry, the more stable it is.

The hardest part is that you don't know how the future will unfold, and some decisions will look wrong in retrospect.
New requirements you never expected to come, will come, you'll need to go back a few steps and adjust.
New opportunities will show up. Some "sure things" will fail.

I fell in a trap of trying a "smart" trick to have all the upsides with no downsides many, many times.
But that's not a trade-off, that's just good vs bad choice.
The fact that there's no smart tricks is the essence of trade-offs.
You need to close some doors, say no to certain opportunities.

Trade-off - a decision between two GOOD options.
I read it a while ago, and it keeps coming to my mind very often.
I realized that saying yes was often easy, but many important decisions were about what I was ready to say no to.
So true in life, so true in software.

I think that additional challenge is that often, that insane amount of work is poorly tracked, especially in cases where those same people have a reputation of "getting things done" and "can be counted on" ;)

Another thing that doesn't get enough attention is "gemba", originally a walk around the factory floor.
In software that can be shadowing a person doing the work, visiting the place where it happens, reading manuals, attending training, doing customer support...
Many ways, but the same concept.

As a Kanban/Lean fan I think that the concept of "muda" is something painfully missing from Scrum and other Agile approaches in software.
It's always more, faster, better until it becomes overwhelming and exhausting.
But sometimes you can gain so much more by reducing waste and tiny improvments.

It happened to me, but after talking to @mathiasverraes.bsky.social I realized that it's not something common. Most "breakthroughs" are less severe and stressful. I think you also need to be more hands-on and stay around for a while to see it through. If it sounds familiar, I'd be eager to talk :)

Question: Have you ever experienced a full-blown domain crisis in your project?
Some misalignment in a core part, very, very deep or fundamental, so big that it was easier/faster to set things aside and rewrite a significant chunk of the system (even whole?) rather than try to gradually improve it?

It can be also liberating to realize how little actually depends on the code itself, even less on its quality.
Maybe that's the best overengineering prevention. When you know how difficult it is to build a successful business you can worry about scalability a bit less, at least early on :P

Reflection inspired by a conversation about a failed startup with a non-technical founder. The app was absolutely beautiful, according to me, and, according to him, the code was pristine too. Too bad they went out of business, and all the ugly, legacy B2B apps from the competition are still around.

What is good about it is that if you get the few key decisions right, then the rest doesn't matter as much.
Yes, there is a mess, but that's ok if it's not constraining your business (too much). If there's nothing you'd wish to improve, then are you even doing anything useful or just goldplating?

In a way, it's even fascinating how valuable and bad the code can be at once, and how little correlation there is between quality and $$$.
There are crises when the mess is too big, of course, but I'm still amazed at how long you can live with it and how far you can get.

But in reality, 90% of the job is fighting the entropy, catching misunderstandings, redoing the same thing for the 5th time, and trying to make it somewhat usable.
If I knew what normal looks like, I'd enjoy and appreciate the remaining 10% so much more instead of worrying that it's so little.

One thing I wish somebody had told me 10+ years ago is that what you learn about software in training, books, and conferences has as much resemblance to reality as Instagram houses to your life.
Yes, there are some useful skills to learn, worthy aspirations to have, etc.

It's exactly how it started for me and I still can't believe I did it twice. Wonderful conference for speakers, even with less experience, very supportive team and nice people attend, so now you have no excuses :P

Yeah, and striving for that balance is a never-ending journey ;) Though I have to say it's really satisfying when you see that the model you found is still useful and able to absorb changing requirements after a few years. Rare but awesome :P

Interesting, I always read it differently - to remember that there's something "as good enough for my situation/context" to avoid analysis paralysis and looking for perfection :D

One more reason to keep all my house appliances as dumb as possible. Annoyingly, it's increasingly hard to get "not-smart" versions of everything.
Why would I want my treadmill or washing machine to fail without an internet connection?
It's more than enough trouble that they need electricity.

Building a house is an endless supply of software inspirations.
It never occurred to us to check if windows had a consistent size across walls, though it seems obvious in retrospect.
Turns out it matters a lot in windows with glazing bars (local style).
If only our architect were Steve Job's fan...

I agree, but for some businesses it's ok to treat devs as just "coders". The understanding is covered by other people or processes.
It's like McDonald's vs gourmet restaurant. It's not the question of which is better, they're different businesses. But do you even know which one you are? :)

Old but seems still relevant udidahan.com/2010/08/31/r.... Crazy how quickly everything changes in software :P