Searching for the state in which Wonderful Things are inevitable
by Gianfranco Alongi (gianfranco.alongi@gmail.com)
“Fear leads to anger, anger leads to hate, hate leads to suffering.”
- Master Yoda
I love this quote, fear is the mind killer; our minds are like parachutes, they don’t work unless they are open. If we feel threatened, we get defensive, we stop listening, we stop thinking clearly, and will make emotionally tainted decisions which sub optimize the value for the company/customer. In short - we will take decisions which protect our ego, instead of solving the problem we get paid to work on.
As programmers working with APL ‘The Tool Of Thought’ - it should be top priority to keep our thoughts unclouded by fear, so we can focus on writing suspiciously powerful and yet alarmingly beautiful APL code.
My team at Ericsson has been through a lot (God bless them) since I joined in the late summer of 2011. By now, I guess there is nothing they can fear any more. More or less forcefully subjected to all kinds of things like TDD, Pair Programming, Crush Sessions, Hero Avoidance, endless Code Dojos and now the latest addition which is Mob Programming - the learning is endless.
I am on the never ending quest of continuously improving everyone around me, so that they will get better than me. Why? Because the best way to get better is by working with those who are better. You can observe, ask, and mimic. Instead of trying to figure everything out yourself, you can leverage the fact that someone can give you distilled knowledge mixed with wisdom, this is accelerated learning.
If we all continuously strive to improve those who we work with, someone is always trying to improve you in return as you are trying to improve them. It is but a matter of time before this little select group is the best of the best.
What I describe is undeniably sensible, although it does require a lot of courage and trust. What I will describe now, is the different practices I have used with my team and other teams in order to nudge the team dynamics in the right direction.
Pair Programming (PP) was the first thing I introduced; two developers working on the same problem, on the same machine. There is much written about PP already, but let me mention the interesting discussions and what I observed. A common misconception that needs to be buried when it comes to PP, is that supposedly productivity would be halved.
This is only true if the productivity bottle neck is the typing speed.
If two developers have a 1:1 relation between their productivity and typing speed, then yes: removing a keyboard would put your productivity at 50%. However, this is definitely not the case.
Studies by Microsoft and IBM have shown multiple times that the so called Read/Write Ratio (R/W Ratio) is our main concern when it comes to working in large software systems. In short, the R/W Ratio in large software systems is ~10-15. This means that on average, a developer needs to spend 10-15 times more time reading than writing code.
Clearly, the main problem is the time needed in understanding.
Two minds will reduce the comprehension time dramatically, there is so much synergy when working in a pair. Just to mention a few things that happen
- We stop following the wrong chain of thought very early.
- We do not get stuck. There is always an alternative idea to try.
- We teach each other tips/tricks related to how we work.
- We have fun.
- We share system knowledge and knowledge about the ongoing work.
- We expose ourselves.
The sixth point (vi) We expose ourselves) is the most valuable and also the toughest one. Exposing ourselves to our colleagues can be scary. A lot of negative thoughts based on fear can pop up. The ego can get hurt, suddenly all our weaknesses which we have learnt to live with become a very apparent and very real issue. Typing speed, system specific knowledge, tool proficiency, coding skills, thinking speed, work habits, every aspect of work will be exposed to your PP partner.
If we do not expose ourselves to others, how can they help us improve?
In order to do this, we must be capable of facing our own fears, we must vanquish them, for they prevent us from growing.
Master Yoda - “That place… is strong with the dark side of the Force. A domain of evil it is. In you must go.”
Luke - “What’s in there?”
Master Yoda - “Only what you take with you.”
Much like Master Yoda told Luke to face his innermost demons, we must do so. Whenever we feel unease, a fear of exposing something related to our way of working or technical expertise - we must take this demon, and put it into our ‘Book Of Demons’. By systematically putting all your technical weaknesses into this list, you not only admit that you have a problem, but you also build a very practical checklist of things to improve.
So, when do we have time to improve? There is no time like the present!
One thing I have found profoundly successful is to practice weaknesses in a Code Dojo setting. Our team has 2 hours weekly, dedicated to deliberate practice. That is; my whole team gets paid two hours per week to practice, so they can perform better. Combine the Demon books from every team member into one huge list, next, take the first item - and whoever is the most proficient in that item prepares a lecture with some exercises for the team to improve on the next Code Dojo.
This works well when the team is motivated or guided by a team member taking point, but what if the team does not have this motivation?
As part of coaching another team in another part of Ericsson, I wanted to nudge the team into doing Pair Programming. At first the team was reluctant, but once I had tapped into the primitive parts of our psyches - they were doing PP.
We are animals, and we have all been living in tribes and clans for quite some time; physical tokens, recognition and rituals mean a lot to us. If we wish to change a behaviour then we can leverage these facts and utilize them. I gave the team I was coaching a challenge:
‘For every time someone does PP in the team, the team gets one Golden Star from me. If you manage to get 10 golden stars within a 2 week period, you get a certificate from me.’
The next time we met, they had done some PP and I held my word, a golden star was put on their whiteboard. The first collective recognition of the team, one of many to come. This does not only bond the team together, making the members appreciate that they are working towards the same goal, it also turns the greatest fear of exposure into a game.
Over time, the team managed to collect 10 stars for PP, and so I ceremoniously produced a diploma, which was given to the team during very formal circumstances with music and a short speech.
Ceremonies matter, strong emotions and psychological mechanisms are at play here, and it was very obvious that the team were happy to have exposed themselves to each other so much.
Another team I coached could not even get started with PP, there was an obvious fear of exposure to each other. The team consisted mainly of older developers who had been in their comfort zone for quite a while now. No one immediately expressed concerns for being exposed, but all the reasons for not doing PP were just blatant excuses. Master Yoda comes to mind again;
“You must unlearn what you have learned”
- Master Yoda
This quote is also a golden nugget I carry with me. Traditionally, people were taught to be subject experts, with a lot of gravitas and a fat nice paycheck to go with it. We learn to crave to be the best, we like being the best, our egos require it. We have learned to be heroes - and will protect this position and feeling that goes with it. Unfortunately, this is actually a counter productive thing.
What this team needed, was to unlearn being heroes. Because the hero does not wish to be perceived as weak. The team got a challenge:
‘For every technical area of improvement you practice together as a team, you get a Brain (brain printed on a magnet) from me. If you manage to get seven brains within the time I am coaching you, I will give you a certificate for your outstanding performance.’
Suddenly, the personal weaknesses become a positive driving force for the team. The team practices the ‘area of improvement’ (a more eloquent way of saying weakness), and gets a Brain token. Soon enough, the team members were ‘sharing ideas’ (admitting problems) they had for improvements, so they could get those Brains. Exposing their weaknesses was now a good thing, a game. The team fulfilled the challenge, and as promised, a ‘Tiger Challenge’ certificate was printed and delivered with music and a speech.
Today Pair Programming is a given in the team, no one sees this as anything but a positive force. In November 2013, I had Woody Zuill[1] stay at my place for a week. Woody told me about Mob Programming and how his team practiced it, I immediately wanted to try this out. Mob programming is PP taken to the next level.
The whole team, working on the same thing, on the same computer.
Surely this is crazy? It is crazy alright, crazy good.
In crisis mode, when you need to get something done quickly, you always gather the best people into the same physical location and give them a lot of space and freedom (with added pressure of course). Why don’t we do like this all the time instead?
My team has practiced this for a substantial period, and it works extremely well for Trouble Reports (error corrections). For normal development we still do a lot of PP, but we pull together into the Mob when the pressure and complexity starts mounting.
When working as a mob, no task will ever halt until it’s done, no team member burns out due to stress as everyone shares the load. We all know what we are doing, and we all know what has been done. No meetings are necessary as we are all there, we all take decisions together, this also means that we can quickly undo a decision. The most important thing is not to keep everyone busy by being stuck and working overtime. The most important thing is to get the most valuable solution out the door as quickly as possible. Every good thing from Pair Programming is magnified tenfold in the Mob.
But, what comes next? Evolution never stops, progress is inevitable. From what I've heard, Dyalog Ltd and Optima Systems Ltd practice something they call ’Swing programming‘ where one developer from each company is traded for a while! I just hope they will write an article on this and share their findings, it sounds really interesting!
Pair-/Mob-/and Swing-programming aside, the search for better should never stop, so let me leave you with this last quote:
“All the right people and expertise,
in the right place,
at the right time.”- Woody Zuill on Mob Programming.
References
- Zuill, Woody http://zuill.us/WoodyZuill/