Tools make fools?

Another great Event Storming session!

You stand in front of a (digital) wall, full of stickies proudly expressing important facts happening throughout a specific place of the system you are working on.

Ah, all those orange stickies!

External systems, actors, commands - looks impressive.

You look around and it seems that you might be the only one so enthusiastic about the result.

Result.

What is the result?

Of course, each person probably desired to get something out of this "meeting".

Is there an ultimate, universal result one should expect from this kind of activity?

Colorful stickies on the wall is probably just a symbol of it.

When we ask people who participated "in the meeting", it turns out that not everyone got on the same page.

Some people didn't understand the notation, some of the got bored about discussing workflow topics they already knew.

Subject matter experts didn't get "why we are doing so" as everyone in the room know how the system is working.

But all the promises...

Microservices - this time we will make it!

Imagine that we got assigned to a challenging task - we're going to modernize a part of our system so that it can better serve our customers and the business.

Thank God we watched couple of videos from prominent conferences, we attended some of them on site.

Kubernetes, observability, serverless, hexagonal architecture, Domain-Driven Design - oh my, so many things to apply in the new initiative!

We group a bunch of people, and we start to design the new system.

"Modules" emerge as if there were mushrooms after the rain - everything is decomposed into smaller pieces, each with its own responsibility.

When we looked upon an architectural sketch, all those independently deployable modules proudly stand out, each with its own color and purpose.

The future looks bright.

Each module gets its own repository, own CI/CD pipeline - and we are ready to go!

People start implementing the modules, and the first problems appear.

When it came to integration, it turned out that modules (and people) are not truly isolated.

Soon managers scheduled coordination meetings and our "independent" modules started to materialize dependent interations between each other.

But all those promises...

What result did we expect?

You need to be more Agile!

Another sprint planning - unfortunately nothing was released to production in previous sprint, but we all hope this time it will be different.

The team is ready to pick items from overpromised backlog, scrum master is ready to dispatch the work to each developer.

Seventeen user stories are in progress, seems like it goes well - there is no minute wasted as all are busy.

Software engineers have some ideas how to improve the product by just adding small features that might make the whole experience better.

Well, backlog is full with predefined epics, user tasks, requirements, and so on.

Designs are provided by external UX people, architects do not contribute in designing the system other than giving "design blueprints" and making decisions.

The further with the Agile journey, the less agile the team is.

But all those promises...

What result did we expect?

AI - no more devs and their laziness!

The Gods sent us the almighty AI!

Now all the problems we had with software development are going to disappear - we will have "agents" at the tips of our fingers (or tongue), systems will "code" themselves in a speed of light.

Or speed of thought.

We order, "agents" do.

"It's another level of abstraction, you don't need to look inside. It's a black box.", many say.

Soon, a flock of unexperienced developers start using AI to produce code, even with tests!

Ha, in your face, "lazy" senior devs!

We can produce a lot of code and add features faster than ever!

Soon, it turns out that no one really understands the code that was "produced".

Bugs breed bugs, which then breed more bugs - people inside of the organization forge a new concept - "Cockroach-Driven Development".

New waves of "bugs" are produced in a speed of light, or thought, if you wish.

Senior developers are not equipped with a proper tools to analyze, understand and re-design parts of the system.

More AI is employed/utilized to heal the situation.

Architects draw diagrams but they are a mere beliefs how things should work but actually aren't.

Cockroaches, cockroaches everywhere.

But all those promises...

Tools?

Human beings are tool-making animals.

As tools are made, they are made to be consumed.

Hence, we are tool-consuming creatures too.

We use them to survive, to make our lives easier, to make our work less effort-requiring.

But behind every tool, there's a philosophy, a way of thinking.

A problem that forced (or encouraged?) people to create a tool so that their work become easier.

This problem manifested itself in a specific context, in which systems (socio-technical constructs) operated.

IT is pretty young industry, still explores and looks for stable approaches for producing value using software systems.

Repeatable processes that bring predictability and stability when it comes to getting results.

Same results.

Every time the tool is used.

Fortunately or unfortunately, tools we use are not like power drills or similar - even though the metaphor seems to hold for most of the time.

Designing, building and supporting products/systems is a complex task, which requires a lot of thinking, understanding and empathy.

All of that is a social endeavour, which requires outstanding effort invested in making everyone aware of the context, the problem, the concepts "living" in the problem area.

As we discussed some time ago in Systems: by, with, for people, turns out that all we do involves human beings.

This aspect cannot be neglected and what's more - it needs emphasis each time we design stuff.

Not only visually but also "internally" - when we name variables, design boundaries around modules or document how to run utility tools.

Fooled by tools?

"Just use Event Storming", "Ports & Adapters is all you need", "F# is the language that solves all the problems" (actually, many of the problems, but I am biased 😉) - have you heard such bold statements, dear Reader?

How often are we lured into this valley in which adopting a tool will make all problems magically disappear?

Tools are "just" manifestation of a solution to a problem, appearing in a specific context.

Does my context seem similar to the context in which authors of a proposed tools were operating in?

What if it's different?

Just pouring "daily standups" or "AI" into our work won't "magically work" - for sure they might postpone the disaster or "fireworks".

I truly believe that one needs to understand the principles, the philosophy, the contextual ideas and concepts behind a given "tool" - whether it's about Agile, microservices, AI or Event Storming.

In many cases it's about human beings - making them more comfortable, less loaded (cognitiviely) or similar.

It's of course easy to say "don't get fooled by tools" and walk over - but how to achieve so?

We can use yet another tool - a question:

It is another form of an opportunistic question - "What does it give to me?".

It puts a frame that whatever gets created, must be organic and positive, when it comes to outcome.

Looks beyond the tools, looking at the new concepts it introduces to the language we use on daily basis, should give us deeper meaning on why we should utilize them.

Ports & Adapters - why one wants to use it and what outcomes it promises to bring?

Agile - why people came up with this tools and what we expect to get back from it?

Aggregates, in Domain-Driven Design sense - what was the context for this tools be used?

First principles

At the moment of writing, AI tools appear sooner that I type the letters, channeling thoughts from my mind.

They all promise bringing efficiency, easiness and impressive results.

It's not I am bashing or neglecting incoming changes - I am welcoming them, knowing what is truly important (to me, at the time of writing).

Understanding first principles, getting fundamentals right, as there are universal and evergreen concepts each software professional need to know in order to create systems that maintain producing value over time.

That's actually I am fascinated by words, by concepts and by language we all use - as it's about certain abstractions we've brought to this world, to make our lives/work easier.

Wait, does it mean that abstractions are tools?!

One could think in that kind of way - I really recommend understanding "our" (= knowledge workers) tools - abstract concepts brought by generations - either they were crafted in 70s or 2000s.

"Are you crazy Damian? Nowadays most of the stuff is outdated!", one might easily say.

Well, I am not denying that, but it's really similar (to me, now, in this context) to ADRs (Architecture Decision Records) - we typically want to have them not for the options we chose, but to understand which options we discarded.

It might look familiar as wise words state:

I don't know about you dear Reader, but to me it seems that it's worth studying the past, to become smarter for the future.

Studying?

Yes, studying.

Learning a concept is one thing, but learning and re-learning it might eventually lead to new insights - every iteration is different, even if it might look the same.

Concepts remain the same, but we change ourselves.

Our sight gets sharper and more precise.

Our thoughts become clearer.

As we walk down the path for seeking greater understanding.

And please don't get me wrong, dear Reader - I am not advocating for living in the academic/ivory tower, without getting our hands dirty.

Getting dirty is a part of studying process.

Inevitable one, I would dare to say.

But just "jumping" into the action, without "training" ourselves in seeing the concepts in action, might not bring the right experience.

Kind of following "what I can't name, I can't use consciously".

What's next?

It's easy to drown in the world full of abstract complexities, brought by other people or ourselves.

Most of the tools were created to work as aid to re-occuring problems.

By understanding the context, we might pick the tools consciously and not be angry that a square peg does not match a circle hole.

Next time dear Reader, when you are going to use a tool (even if it's 100th time this year), ask yourself: