f3yourmind

I shared by thoughts on people dynamics and how it affects success of software development projects with Yuanfang Cai yesterday.  In particular, I was explaining my thoughts on how diversity in a team affects the performance of a team.  When I talk about diversity I mean a lot more than just culture, language, and timezone.  I also view diversity in terms of value systems, political affiliation, economic position, overlapping worlds (such as work world overlapping with home world).  But my weirdest interpretation of diversity is that of diversity based on team boundaries.

Traditionally, each team has a boundary.  This boundary determines whether you are included or excluded from the team.  Sometimes, the inclusion and exclusion rules are clear, which is a good thing.  Sometimes, it is not.  Regardless, the boundary exists to eliminate diversity.  But, there are too many edge cases of people being brought into the team for a short while, then leaving.  The position taken is often “Joe is not part of the team, but sometimes we need him to join in so that we can …”.  Well, teams don’t work like that.  Let me rephrase: GOOD teams don’t work like that.

What I explained to Yuanfang was that I don’t think a team should have boundaries at all.  Instead, everyone is part of the team.  However, some people have a strong force that attaches them strongly to the team and others are attached by much weaker forces (like Joe’s part-time involvement).  When, you think of the team constructed via these forces, then the team can still work from one value system.  Why?  Because the degree of adoption of the value system is independent of the strength of the team forces.

Try it out and, maybe you will get greater harmony in the team and increased collaboration too.

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.

Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

In a couple of weeks I will be at the OOPSLA conference in Orlando, USA.  I am absolute OOPSLA nOOb but am already excited about it.  I’ve heard lots of nice things from the OOPSLA “veterans” at factor10 and now I can’t really wait to get there.

I will be giving a tutorial on using AOP to solve some domain problems, not just removing the infrastructural noise from your domain models.  Also, I’ve been invited to be part of a panel on my best-loved-hated subject … modularity.  I will also take part in the Cloud Computing Design workshop.

There’s also an amazing line up for the other tutorials and OOPSLA still has a “Pay for 3 and attend 4″ promotion going on.  Take advantage of it.  If you already signed up for 3, then just sign up for the 4th.  If you’ve signed up for 2, then pay for the third and register for the 4th too.

So much happening in just a short week.  But, it will be lot’s of fun and worth the 24 hour travel time from Cape Town.

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.