f3yourmind

I am amazed, yet again, that people try to force others to comply to a process, standard, or whatever.  The traditional justification is to ” have governance otherwise everything will fall apart”. Surely, we have learned enough from spectacular failures that governance that does not give people an opportunity to exercise self discipline.  When you give a person a chance to develop personal discipline, then forced compliance is unnecessary.  With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you.  It breeds an attitude of “the system failed me and it’s not my fault”.

This discipline I am talking about is a personal attitude to everything.  Some things may be the discipline to

• not check in code that is broken
• fix your own or someone else’s broken code
• find options for looming failure
• be accountable when you’ve accepted responsibility
• admit error when you make a bad judgement
• commit to learn in the face of ignorance
• share because you just should anyway

Of course, I am being deliberately idealistic.  But wouldn’t it be really nice if everyone just accepted discipline as something that needs to be developed personally.  Imagine it for a moment … so many XP values and principles seem a lot easier to adopt.  Just imagine it.

A forced compliance style of governance is a lot about trying to compensate for lack of trust and admitting that we are more likely to fail than succeed.  On the other hand, discipline is not pain, suffering and anguish.  It’s only sadistic if you implement discipline for nothing.

In ubuntu coding, discipline is a necessary quality.

Last week on the factor10 DDD course in Cape Town, the question of reusability came up again.  It’s the same old object orientation promise of “Just do OO and you get phenomenal reuse for free”.  Today, I was refactoring some code with another developer at a client and I extracted some lines into a few private methods just to clean up a really fat loop.  The initial reaction from the other developer was “That’s an overkill because you won’t reuse that method”.  My spontaneous reaction was “Readability is the real reusability”.

It’s true, the method won’t be reused.  It’s also true that most us were taught in some Programming 101 course that you should create a method, function, procedure only if you are going to call it more than once, otherwise just leave it all inline.  I value ubuntu coding, and so I have learned to unlearn that naive rule.  When I make my code more readable, I get more reuse out of it.  The reuse I value is not really about the number of repeated method calls or number of inherited classes.  I value the increased reusability that is achieved when more developers are able to read my code and walk away understanding my intention, clearly and unambiguously.

Let me put it another way.  Your code is a representation of your model.  Your model should be used to drive all collaborative discussions about the solution.  That’s where you get the real reuse in your model.  If people can’t understand your model, then your model can’t be re-used for further discussions.

The other night I was driving home quite late from the airport.  For that hour, the roads are quiet and it’s a relaxing drive home that gives me a chance to think back on the the day’s events.  At a red traffic light, I stopped, but some idiot in the lane next to me rushed straight through.  You know what happened in the next 5 minutes.  Lots of honking, screeching tires and near crashes.  Fortunately, there were not accidents and nobody got hurt.

Really?

No!  Even though there wasn’t this big crash, someone did get a fright of their life, even I as an observer got a fright. And someone else did continue their journey quite shaken and certainly not in their same frame of mind.  The only person that seemed to be least affected was the person who jumped the red light.  But I am speculating, maybe he was under pressure and really needed to get to the end on time, and so he rushed ahead and saw in his rear view the potential destruction he left behind.  And maybe he regrets his decision.  But he certainly did not see how his actions affected the other people that were close by, myself included.

Driving through a red light can kill you and you can kill other people too.  The same thing happens when ignore the red light from your tests.  You can hurt yourself and you can hurt other people too.

Just think about that red light at the traffic light and in your code.  It’s telling you so much.

• It’s telling you to slow down a bit.
• To look around.
• To think about the moment.
• Don’t focus on the end, you will get there in good time.
• If you ignore the red light, other things will break and other people will get hurt.
• Maybe you don’t know why you must stop, but you need to stop first, before you can find out why.
• It’s telling you to do the right thing, not the rushed thing.

Driving through a red light is another suicide pattern that I will add to my growing list.

And TDD is also part of ubuntu coding.  I am not telling you anything new.  I’m just telling you the same thing from another perspective.

The ICC Champions Trophy is on the go in South Africa at the moment (… I’m talking about cricket).  Yes, the Proteas failed in a big tournament (again!) but the Poms will be touring here this summer.  As passionate as Saffers are about their national teams, we also seek revenge, but in a nice way;  I mean face-to-face revenge, not back-stabbing revenge

So with all this cricket frenzy going on, I caught an amazing interview with the captain of the Pakistan team, Younis Khan, on cricinfo.com.  For a person that lives in a country that is literally self-destructing, he views his purpose not just as a captain, but as citizen of a troubled country.  He views his influence on the team as lasting.  Like he says in the interview, when his time is up, he wants to leave with dignity and that which he leaves behind is more important than what he takes with him.

That is what I mean by Ubuntu coding.  It’s more about what you leave behind than what you take with you.  When you leave behind a code base that someone else will enjoy, then you are already more than 50% down the path of helping yourself.  If you left behind a mess, then you breed more messy developers.  I’ve stopped asking “What will I get out of this?”.  I think more about “What will you get out of this?”.  That subtle switch in perspective is enough to make me realise that the value is in what I leave behind.  It also means that my search for quality and fulfillment is in the moment, not some future time which may never materialise.  Now, I stop chasing some future desire and appreciate the quality and importance of now, and realise that I what I leave behind is significant – good or bad.

There is also a comment from Younis about coaches.

In the senior team there should be helpers who are also coaches, like Bob Woolmer was. He was a coach but he helped out with everything – in bowling, in life, in stretching, in luggage, in everything. This is not football, where you need to have that kind of coach. Here in cricket it is in individual game in a team game.

This feels a lot like coaching software developers … individual game in a team game, and that experienced developers need nudges and guidance, and noobs need technical coaching.  And as a coach, you need to help out with everything too.  I recently realised that I don’t help out with many things.  Actually, I don’t want to either.  It’s not that I can’t help, but I just can’t multi-task and be effective at everything.  I am the kind of person who multi-tasks and delivers less than 100% quality on each task, but when I serialize my tasks, I hit 100% quality quite often.

So, here’s my take on coaching software teams.  It’s sometimes like cricket, and sometimes like football too.  You need many coaches.  Coaches that work with technical things, people things, process things, communication things, management things and all sorts of things.  I know that I suck when I try to do people and process coaching at the same time as technical coaching.  It’s the thing that Peter Hundermark made abundantly clear to me over the last few weeks.  Now I know why he says that Scrum masters can’t be product owners, or can’t be part of the team, all at the same time.

That is also the reason why I can’t create miracles.  The people that have had greatness bestowed upon them; Mahatma Ghandi, Martin Luther King, Nelson Mandela, and many others; never created miracles but they allowed the people that they influenced create their own miracles.  Good software coaches are like that too.

So, Younis Khan and I are not related in blood, nor in career paths, but I have learned from an unlikely source with a very similar name.

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.