Slow down

It's a nonsense

There are seventeen youtube videos waiting in the "to watch queue".

Books are piling up mercilessly.

New tool here, new tool there.

Take a breath. Observe.

And then a random guy (me) posted a clustered group of pixels, viewed as characters by our eyes (brain?), on twitter, referring to this post. Yet another article to read?

The title isn't helping - "what a BS, slowing down?"

Did I go crazy or something?

The non-renewable resource

The perception of time is a massively interesting topic (the perception itself is interesting too!), there are vast number of perspectives and symbols how time can be represented (modeled?).

One of such views is the time as a resource - something you are not able to produce yourself.

In theory you can't, in practice you can, but you need other people, machines, intelligence and so forth.

Typically in IT business, we want to optimize the usage of this resource to quickly deliver the value to our users by shipping software so that we can gain the feedback.

The shorter the feedback loop, the faster we can learn.

The faster we can learn, the more adjustments and actions we can do.

One could say that's what Agile mindset strives for (What is agility? How does it position itself against fragility? Please check (Fr)Agile)

Speed is good, isn't it?

Attention!

As always, everything is contextual. All need to obey the laws of The King of All Kings - The Context.

The same is with the time.

In (Fr)Agile, I wanted to convey a message that ceremonies without understanding of the problem we are working on, thinking how to properly (what does it mean?) distribute responsibilities, will only make us fragile, rather than agile.

And for sure we're going to specify those responsibilities, draw boundaries incorrectly, at some point, even initially.

So we shouldn't trap ourselves in so-called "analysis paralysis". This might lead to another "dreaded" beast named as "big analysis upfront".

(it's funny that we humans tend to slide from one extrema to another extrema, but that's a topic for another tale.)

Nevertheless, who are the friends of the analysis? Knowledge and understanding.

I like Feynman's perspective on knowledge:

So to gain the knowledge, to explore the topic, and to build up intuition, understanding - we need to pay (with) our attention.

We need to use our non-renewable resource in order to decompose the problem so that later we would be able to compose, but this time knowing.

The final composition will be the act of design. Crafting the subsystems so that their collaboration brings something bigger than the sum of them. The system (which is a subsystem of another system, etc.).

But this needs...Attention.

The time - the apex predator of the design

I love how The Grug, Brained Developer stated:

apex predator of grug is complexity

Any complexity? I believe our fellow Grug was talking about the accidental complexity, which is limitless (What am I talking about? Please check Essentially bounded, accidentally unlimited).

Still we are left with essential complexity, the nature of the problem we are working with.

To properly understand what a beast are we going to dance with, we need time.

We need to focus on learning, building up the confidence so that we would be able to change our mind later on, when the level of ignorance will go down.

But again, it's a cost.

To understand how subsystems, or "boxes", collaborate, so then later we can assign responsibilities - it requires our time.

This sounds a bit contradictory to be fast, isn't it?

Slow down to be fast?

Dissecting bigger subsystems into smaller subsystems is here for quite a long time (pun intended). (You don't have time, because of learning next gen framework? Please check Software Engineering for busy parents)

Specifying how they need to work together, organize themselves, so that they achieve the overall goal - isn't it how we, humans, operate? (Are software components like humans? You can read more here "Organization-Driven Design")

Exploring the problem by specifying the contractors, the nature of their collaboration, is a pure learning exercise, experimenting with various models.

Of course I am talking about TDD (Why did I use "specifying"? Please check "The ambiguity" of TDD).

Writing the specification declaratively, before any "behavior" happens.

We don't know how things are going to work, but we need to pay attention on the observable behavior.

It literally slows us down, because no production code is written until we imagine what we want to get out of it.

And I consider it as a good thing.

I believe that this understanding is what we often miss. It's easier to add "just another if", "new private method" or whatever we need do to achieve "done" status of our task.

Slowing down, devoting time to build up the internal model of the problem in our heads, is crucial to move fast later on.

Especially in times when everything is bubbling up so rapidly, shouting to get your attention even louder than before.

What are you optimizing for?

There are a lot of pitfalls and potential traps a TDD practitioner can set up for oneself.

But testability of a subsystem is a widely advocated trait that when pursued, should pay off quite soon.

I like the statement from "Effective Software Testing: A developer's guide":

Some developers argue that designing for testability is harder and costs too many extra lines of code. This may be true. Writing spaghetti code is easier than developing cohesive classes that collaborate and are easily tested

Working toward testability ("replaceability" or "removability" - it has different names) costs, but what do we really optimize for? For the lowest number of keystrokes? For not too many classes or functions?

The currency is time and "frustration" might pop up - suddenly we are forced (by ourselves) to think, to analyze, to pose various questions.

Be slow to get flow.

Is it easy? Oh no. It's so entertaining to grab your IDE and start typing keywords of your favorite language, but as it was written in Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development:

High quality software is "hard" to achieve, because you need to pay (with) attention.

We can't ran away from putting the effort in decomposition, design, composition. How much time you will or can "pay" depends on the...Context.

Investing "time coins" in problem exploration, solution exploration (some models are going to be thrown away!) the readibility of the code, "just-enough" design (which means some design!) - I believe this is what we should put attention to (pun intended).

To be prepared for the flow of changes we need to learn, slowly.

Slow.

Down.