Architectural Agility - Part 1

Software Engineering is a wonderful world full of surprises and challenges. We learn early on in life that any activity that floods your system with adrenaline is an addictive activity.
In the life of a ten year old, this might take the form of climbing a tree for the first time, ascending to seemingly unreachable altitudes with a non-zero probability of following that up with weeks of hospitalisation.
In the life of a programmer, this might be the result of producing thousands of lines of code under deadlines that you never considered even remotely realistic.

Let's face it: the feeling of impending doom is just great.

In the life of an architect, the main perverse sense of doom and destruction originates from the fact that you are supposed to shape the system in your head, then somehow implant that picture in the heads of over 50 developers, and pray that you've been clear enough with your specifications.
The uninitiated might rightfully ask "Why? Just write the darn specs and pass them on: if they're good developers, they'll work them out..." Alternatively, "Ever heard of agile?".

Well, I don't know about the rest of the world, but in my projects I've never managed to do either. Usually, the situation involves very vague or even yet-to-be-discovered requirements, and only one or two agile developers in a team of 50-plus. So how have I managed so far? Well, it's surely a continuous learning for me, and I still discover something new almost on a daily basis, but here are some points that I have picked up along the way and found very valuable.


#1 : Learn how to produce on-the-fly specs
Why? Because on one hand I have this very hazy and almost monochromatic picture of the requirements, on the other hand I have 50 developers expecting fairly detailed specifications of what they are going to produce, and somewhere in the middle I have a bunch of reasons for being unable to cultivate an agile team.

#2 : Learn how to be ALWAYS available for the team
Why? Perhaps it's just me, but on-the-fly specs are NEVER good enough.


#3 : Learn how to monitor progress all the time
This doesn't mean to become a control freak, but rather to understand the dynamics of the project and minimise the risk of producing the wrong thing due to sub-optimal specifications. Why? Because 50 developers, over (officially) 8 working hours in a day, makes 400 hours/day of code writing and testing time. In one week, that's at least 2000 hours, or about one developer/year worth of effort. That means that failing to convey an architectural concept for the system and leaving 50 developers alone for a whole week translates into seriously refactoring one developer/year worth of code, which is not something you usually do in your spare time. It's like steering the proverbial oil tanker: one mistake in plotting the route, and it will take considerable effort trying to get it back on the right track if you don't spot the mistake right away.


#4 : Functional refactoring is inevitable
Why? Well, due to all of the above. However, I tend to view refactoring as falling into one of three categories: architectural, functional, and schematic.
Architectural refactoring is serious: that is what happens when we change parts of the architecture , for example when half way through the project we realise we need a caching framework for our web application.
Functional refactoring is somewhat less serious and could be considered a minor version of architectural refactoring: that happens when we change some of the application's behavior, for example when we move hard-coded values to some configuration file, and surely when we are bugfixing.
Schematic refactoring is standard routine: that is when the application's functionality is unaffected while changing its internal structure, for example when we abstract common functionality from several classes into one parent class, or formalise common class contracts into interfaces. I'm now learning to shape functional refactoring into an agile project in its own right, and probably write some considerations on that in another post.

M.

The Eternal Beginner

Recently, I've been thinking about my learning journeys in the wonderful world of Takemusu Iwama Aikido. In particular, I've been trying to understand the changes in my "learning methodology", for want of a better term. In other words, how do I actually manage to learn a technique, and how has that approach changed over time?

I could go on for days trying to explain this, but I'll try to summarise the main ideas here.

When I first started practising Aikido, I would try to learn a technique by thinking only of my own body movements. I would look at my sensei offering his right wrist, moving his right foot a little on the side, settle his hips, then turn 180 degrees and face the other way, before adjusting his left foot into hanmi. I would then try to replicate the exact movements, step by step, with clumsy results at first, but then progressing to make my moves smoother and more efficient. The whole process would be based on the mindset of "how do I move my body so that I end up in this or that position?".

I later figured that analysing my own would only be stage one (out of many) for learning a technique, and nowadays I try to learn a technique by going through as many stages as possible, as I'll shortly explain.

Stage two is when I start to look at my training partner's movements instead of mine. Different people have different body shapes, different statures, different degrees of mobility, and so on. It wouldn't make much sense to me to learn a technique through one sequence of my own body movement, and expect the same sequence of movements to work without fail on any training partner. Stage two would therefore be based on the mindset of "how do I move my body so that my training partner ends up in this or that position?".

Stage three is when I start considering the communion of the situation. It's not about my own body, or my training partner's. It's about the combination of both: what shapes they make, what balance they achieve, and so on. This is where my mindset goes somewhere along the lines of "how do I move my body to induce my training partner to move in such a way that we both end up in this or that position?".

The next stage is about direction and redirection of energy. This is when I usually focus on the "path of least resistance": if it's hard to move around my training partner in a particular way, then chances are it's the wrong way. For example, if my training partner is pushing, why should I push back? It's a lot easier to follow his/her lead and pivot around that energy vector, modifying (even if only slightly) the vector's components. This then leads my training partner to follow the new vector, so my mindset would then be "how do I move my body to redirect my training partner's energy in such a way that we end up in this or that position?".

I noted that there is a very clear similarity between the last two stages of training awareness, but there is also a very important different: the former is static, whilst the latter is dynamic. I have also noted that all of the above stages are still focused on my own body movements, albeit with very different mindsets, and I find this extremely interesting because, at the end of the day, that's what I think is the actual nature of a martial art: mind over body.

I am sure there are many more stages of training awareness, but that's pretty much where I am at the moment. For example, for anyone knowing this terminology, all of the above are my consideration on ki-hon forms. I haven't even started considering the type of mindset involved in ki-no-nagare forms. Who knows, maybe one day...

M.

Hi There

Call this a warning, a disclaimer, or whatever you like.
I'm starting this blog to share my personal views on different subjects.
In other words, these are my experiences, and these are the ways I've travelled my own path.
It's just a bunch of information that someone might or might not find useful.

In the end, if only one person finds any of this stuff useful in any way, then I will have done something good with my time.

Enjoy.

M.