Dragan Stepanović

Let me think about it.
Hmmmm...yeah, people will vomit more (even worse) code.

Nobody ever got promoted for solving an exponential problem in its lag (still slow growth) phase.

The problem with any economies of scale is that the immediate cost savings they provide obscure the costs of a lack of local resiliency, which are observed only later.

And it's far from guaranteed that the latter won't be higher than the former.

It's amusing to observe the sheer amount of "Not Invented Here Syndrome" present in "BigTech" companies by the extent of different language used for already ubiquitous terms and ideas in the industry.

That's to say, teams that struggle with refactoring skills are also teams that most likely struggle with design skills, because tapping into a rich pool of domain and design insights generated as you refactor in small, safe steps is out of their reach.

2/2

If you can't change design cheaply because refactoring skills are lacking, you're less likely to end up with a suitable design for a given problem that emerges from insights you get as a byproduct of refactoring.

1/2

Reminder: the Call for Sessions for next year's Agile Manchester conference in May is currently open: agilemanchester.net/call-for-ses...

/ @agilemanc.bsky.social #agilemanc

I wanna join!

But then I won't have the chance to practice my skills for reverse engineering understanding from the implicit code!

Sorry, it was a response to this LinkedIn post, which provides more context.

@JellyTBeagle@plush.city 20 years ago, normal people avoided technology and techies would jump on the newest gadgets as soon as they could now, normal people buy smart toasters & coffee mugs while every techie I know is on the verge of retreating to the forest

True!

plush.city/@JellyTBeagl...

There's a feedback loop that feeds from making the changes to the quality of the mental model of the problem and domain

In doing the work, and if you listen carefully, you get to discover more about the domain and problem that feeds back into the way that you do the work.

2/2

One important questions to ask is: "What amount of domain insights are you missing out on by handing off creating the changes to the machine?".

Can you quantify that? :) Way more difficult, if not impossible, compared to "saved X hours creating this feature using AI".

1/2

fuck yeah

So, the point is not reducing the cost per se. It's fixing the problem that the high cost of change pointed at, which in turns dissolves the problem of the high cost.

4/4

In a bunch of cases, the high cost of change serves a purpose. It points to a problem, addressing which reduces the cost that was pointing at it.

3/4

And my experience tells me that there are a lot of the latter ones that for lots of teams/orgs go under the radar, deferring addressing painful problems for a way longer time than they should.

2/4

I often ask myself if a technology, beside lowering the costs for which lowering the costs is beneficial, is also lowering the costs for which lowering the costs is detrimental.

1/4

I can notice the pattern, next talk is "Beyond UUIDs"

I heard there's this GOTO conference.
I think it's trying to popularize long forgotten tool of great software designers: GOTO statements.
You should try those as well.

I think SonarQube should also add it to one of their mandatory rules.

Amazing. That's already 5 Jira tickets done.
Hope you also tested some constructors and getters along the way.

That's all fine and dandy, but Nick did you test private methods?

Again those pesky reinforcing feedback loops and exponential behavior that humans are so good at understanding...

If you manage to do that, it's already a huge competitive advantage that is a blind spot for most, if not all, of your competitors.

Quantifying direct costs of multiple people working together is way easier than quantifying this one, but I'd bet my money that the latter is less expensive. And it's not the only one that you'd incur.

Don't get fooled by a bias of focusing only on the metrics that are easy to measure.

What are the costs and implications of a fragmented mental model of a domain across the team that you get as a result of people working in isolation?

The only way to protect your future is by taxing the billionaires more.

At the @makethempay.bsky.social rally today.

The tyranny of economic growth obsession.

I heard wealth will trickle down one day, we just need to lower taxes again for them.

Eu sei!