Tag Archives: ubuntu

Driving through a red light can kill you

Posted on by

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.

Younis and I are not related but …

Posted on by

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.

Pass the Parcel

Posted on by

Fiona and I are planning Lia’s 5th birthday (27 July!) and a favourite kids’ party game is Pass the Parcel.  Kids sit in a circle, and there’s a surprise package with wads and wads of wrapping.  Music plays. Kids pass the parcel around. Music stops. Kid with parcel removes one layer of wrapping.  Music plays, pass it again.  And the last layer removed reveals the prize and that kid gets to keep it.  Do it once for each child, carefully timing the music and every kid is a winner 🙂
It reminded me of this business of tossing artifacts from once person to another in a development team.  In waterfall, it’s obvious who has what and what layer is peeled off when.  In fake agile(*), it’s not so obvious.  You know the music is playing when people ignore responsibility and toss it onwards or backwards.  The only difference, is that the party game everyone wins.  In the software game, everyone loses.

A few years back I sat in a class where Kent Beck explored XP with ten of us for a day.  For the first time, I realised that XP was less about coding practices and more about being decent people.  If I wanted to write quality software on time, on budget, etc. then I needed to have courage to accept responsibility for everything.  I don’t need to do everything, but I needed to feel responsible for everything.  No more passing the parcel, when it was convenient for me.  To do that, you need courage and respect.

Somehow, it feels like an Ubuntu coding thing again.  If you pass the parcel, make sure the receiver has good chance of winning the game.

(*) When the teams says they’re agile, practice agility mechanically, but don’t live by the value system which will make them agile in their heads.

Ubuntu Coding for your Friends

Posted on by

Last week I gave a domain driven design course and one slide I put up was titled “Coding for Friends” with a single message “Avoid conceptual corruption”. In other words “Code so I can understand you and you don’t screw up my mind”.  I did not realise the significance until I started working through the practical exercises with the groups and kept on referring back to this simple idea.
So often we write code in isolation and the code reflects our personal interpretation of the problem and a personalised solution too.  We easily forget that other people will execute this code, modify it, and, at the very least, read it.  Coding is a social exercise first, then a technical exercise.  We have a responsibility towards increasing the probability of success for the next person or team that will work this code.

We can write code in isolation that is of high quality, focusing on self and metaphysics of quality, etc.  That’s a zen view and it is about you.  I like to think (believe?) that Ubuntu is zen for a group, not for an individual.

In Zulu, the Ubuntu philosophy is summed up as

Umuntu ngumuntu ngabantu

which roughly translates to

A person is a person through (other) persons

And in geek-speak it is

A developer is a developer through (other) developers

I get better because you make me better through your good actions.  And the opposite also holds true: You get worse at what you do when I am bad at what I do.

How do we write ubuntu code?  It’s not hard.  It’s based on “old” principles and wise words of many people.  It’s old material but worth revisiting with ubuntu glasses on: when you think about what the effect is on other developers and what the reciprocal effect will be, back onto yourself.

Reveal your intention, not your implementation. If you have designed a project management app with tasks and decided to implement it as a graph, call the class Task and give it a method called resolveCyclicDependencies().  Don’t create a class Node with a method called topologicalSort().

Avoid side effects. Let a method do one thing, and one thing only.  It’s frightening how many developers don’t do this.  For example, if you add a line item to an invoice, don’t update the total.  Have something else that calculates the total.  Basically, be boring and predictable.  I long time ago a SQL guru looked at my code and said “The optimizer does not like fancy code”.  Same thing.

Broken metaphors. Metaphors exist for conceptual understanding.  Once you get the conceptual break through, leave it.  It’s ok! Trying to build an economic model with a metaphoric model of fluid flows (or bears and bulls!) will just create havoc downstream.

Where am I? Figure out where you are in the bigger picture.  Are you upstream or downstream?  Is someone going call my code to create that Book object? Am I going to call someone else’s code to get the Customer object?  In other words, know what you supply and what you consume.

Fail fast. Assert! It’s allowed in production code too.  I would rather fail quickly and dramatically than delay the effect until it is obscure.  More importantly, when I read an assert then I know that the particular condition is critical.  It is an invariant that must be honored.

Pairing. Programming in pairs is an active exercise, not a case of a second syntax checker.  I see many teams that pair mechanically and it does nothing for increasing code quality at all.  If you practice active pairing, you are closer to ubuntu coding.

There are other techniques which increase the collective responsibility of your design and code such as context maps in strategic design, values and attitudes such as responsibility and feedback.  I’ll deal with those on another day.

But for now, I think that

Code is code through (other) code!

Do you have any other ubuntu coding techniques? Attitudes?

Resurfacing Diversity Challenges

Posted on by

I got a tweet from Clive Seebregts which pointed me to an InfoQ article that made reference to an old Hanselminutes podcast that I did.  It’s nice to see that diversity is not being left in the wilderness and that other people are thinking about it again.  It seems like some people are trying to promote diversity and others are trying to manage the challenges of diversity.  Hmmm, somewhere there is point of brutal contact, but it will be for the good.
BTW, digging around on material diversity in agile teams I came across this video.  I didn’t know it existed at all.  Suddenly, the references to the FIFA 2010 World Cup seem sooooo dated.

Trust Everything

Posted on by

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.

Coding for Enlightenment

Posted on by

Jimmy Nilsson asked me in an email a few days ago “How’s life?”.  I’m sure it was just a regular, friendly question, but I gave him a “life” answer.  It was not spontaneous but something that has been brooding in me for a while.   It is about things that I have been trying to do for a long time.
Here’s a few splintered thoughts from my email exchange.

  • Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
  • There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
  • Code from my heart because I should trust myself first.
  • Be part of the exploration, not just an observer.
  • This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
  • Passion is constant whether I succeed or fail.
  • Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
  • The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again 🙂