Inverse Bruce Lee maneuver

"It's just a status"

Imagine the following scenario - you are exploring a new case in the area of business that you work in.

It eventually needs to be covered with software and by the premise of Alberto Brandolini's ingenious observation - "software development is a learning process; working code is a side-effect" - you need to build your understanding.

The team stands up and heads to the meeting room with a loooong wall, perfect for Event Storming.

And then you hear a statement: "Well, isn't it just a new status?".

Everyone stopped walking and looked like frozen statues.

"A new status?", asked someone from the crew.

Few message exchanges after, you already know how it's gonna end - yet another status in the database.

"That was too easy", said a senior.

"I like those easy solutions", a junior added.

"Oh no, another status?!"

Couple of months later you sit in the war room.

People are nervous because a critical bug stops customers from using the product your team builds.

The team analyzes status columns - 4 in total.

"And don't forget the flag for completion!", a senior added.

"Did you include information from a 'Packages' column? You need to take count of them into account!", another senior yelled.

Eventually, the bug got fixed.

Turned out that 4 status columns, 3 flag columns (boolean status) and 2 implicit status columns, needed to be synchronized.

Who'd have guessed!

"Maybe we should add another column that will be an outcome of all other statuses? Something like final status?", a principal engineer added.

You initially felt it might not be a good idea but it's democracy - people voted and new, shiny column FinalStatus landed.

"Visitor? You must be kidding!"

In one assignment you paired with a senior to provide a solution to a problem that characterizes with strong variability on both ends - behaviors and targets of these behaviors.

At the beginning, there is only one behavior and there are two targets of it.

You both code it with a simple pattern matching on type - works like a charm.

In the next sprint, there's a new behavior and three targets.

The service method grows - it looks a bit scary but hey - complexity means that smart people are working here, right?

In the sprint after, you land with 7 behaviors and at least 10 targets.

"Maybe we should use a Visitor pattern?", you suggest gently.

"No one uses design patterns. They are sooo lame and oldfashioned!", your companion answers.

"And additionally, the level of indirection will kill us - it's one of the most complex patterns in the wild!", he added.

You looked at the service method length and nesting - you need a drink, immediately.

How many kicks do you know?

As a child, I heard about Bruce Lee.

His attitude, teachings and movie roles he played became an inspiration that shaped the way of thinking of young me.

Bruce has many famous quotes and one of them is the following:

My interpretation of it might be similar to yours, dear Reader - it's worth to be greatly experienced with a single method, instead just knowing many methods not covered with practice.

And it makes sense.

"Single kick fighter", equipped with countless hours of mastering it, might be a deadly opponent.

We might find analogies in other contexts too.

What if, just as a thought experiment, we try to map this quote into software engineering realm and treat it a bit metaphorically?

With high chances, we could say that a kick might be thought of as a technique one knows.

Then, a technique might represent a knowledge or an approach in IT context.

So, how many "kicks" do you know, dear Reader?

How many of them did you "practice"?

How many of them are you still "practicing"?

I know that Bruce Lee mentioned "practice" and it would be hard to practice everything of what we read or know.

But by reading all the articles about microservices, we don't need to "practice them" to figure out that in our 4 person team might not benefit from this deployment architecture.

One could say that in the knowledge working industries, the awareness of something is a good enough starter.

Almost like in Matrix, when Morpheus verified Neo's "I know karate", we can analytically "practice" (or "simulate") the application of a given "kick".

It does not translate 1:1 with real practice, of course.

Nevertheless, should we, IT professionals, practice only a single kick countless times?

Inverse Bruce Lee maneuver

I believe it makes sense to broaden our horizon by exploring other methods, techniques or tools.

We have the possibility to do a small exercise, write a "TODO app" or try to apply the given solution to a toy problem.

We could have a "100days" approach and test out single "kick", necessarily followed by reflective time to get the essence - lessons learned.

Even if it isn't a "production grade" experience, pointers to the knowledge are something that we might use quite easily by almost doing what Neo got - "I know karate" kind of experience.

It will take time, no doubt.

One could say that as engineers, we should study various "kicks" so that we have the "know-how".

It's worth having a toolbelt with various appliances and tools hanging, ready to be used.

That's why it's so important to read and explore other programming paradigms, other ways of modelling and representing information.

Hardening the skill of a "single kick" might feel neat but it is all about the knowledge.

Do you use C# on daily basis? Try out F#.

Are you F# afficionado? Check Elixir.

Are you using statuses and booleans in your React app? Read about state machines.

It might feel like a worthless act of "reading" and not building - but we all need to start somewhere.

Patterns: be aware but beware

There are recurring tides of "hate" on OOP, FP, DDD, TDD, Design Patterns, UML, put-your-favorite-thing-here, etc.

It's all knowledge.

I firmly believe that studying all of them might be beneficial for understanding and getting those 10000 kicks that Bruce was mentioning.

As Gerald Weinberg stated in Rethinking Systems Analysis & Design:

Often, it's about patterns - the language we use to communicate, not a particular implementation.

And "loading" concepts into our heads enables next level thinking about the problem - and the solution.

Of course, there's a trap.

When one reads about "Aggregate" or "Domain model", he or she might look for cases to try it out - and we all know that quickly we jump into "when you have a hammer everything looks like a nail" kind of bias.

So it really makes sense to be aware of the "patterns" or "models" but beware of applying them blindly.

That's the core intention behind designing. As Gerald Weinberg concluded in Rethinking Systems Analysis & Design:

So we, engineers, should be able to use various models - check if they match our needs, evaluate their usefulness and pick the suitable ones.

To achieve so we have to "know and practice those 10000 kicks".

"know-how" vs "know-when"?

So "Inverse Bruce Lee maneuver" should guide us toward being open and exploratory in our efforts.

We need to have expertise to be productive and have preferred tools - especially when deadlines are tight or the area of problem/business acitivity is not trivial.

One could say that this might lead to overengineering the solution pretty quickly - and what about underengineering?

Know your context, the king of kings.

So it's about timing? As in the great quote from Gerald Weinberg's Rethinking Systems Analysis & Design:

So it's about knowing "patterns" and approaches but also about "evaluating" the situation, the conditions, the driving forces.

And also about knowing the timing of their application.

It has dual nature though - there is no "know-when" when there is no "know-how".

We need to have the knowledge - shallow or not, this opens possibilities for development and further practice.

Look beyond a single kick, dear Reader.

Remember that there are punches too.

And the head is one of the most deadly weapons we have.