f3yourmind

I have no idea what I’ve gotten myself into now, but I’ve agreed to help out the Empirical Evaluation of Software Composition Techniques workshop will be held as part of the next Aspect Oriented Software Development conference.  I doubt I will attend ESCOT or AOSD but it will be good to collaborate once more with some very enlightening people that I met at OOPSLA last year.

I guess I’ve got quite a lot of reading coming up and it will be fun to read what is coming out of the research channels and cast my own weird industrial perspective on things

One of my contributions to 97 Things Every Programmer Should Know will be included in the book.  My good friend and colleague, Niclas Nilsson, also has a contribution which will be in the book as well.  But don’t just read mine, read all 97 and the amazing contributions that did not make it to the printed book as well.  I have know idea how Kevlin Henney managed to select these 97 things from so many contributions.

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.

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.

It was a privilege in itself to be invited to speak at Scrum Day but my expectations were blown out the water.  Knowing some of the people behind the scenes made me realise, again, what can be achieved when you put a bunch of talented people into a room with a common purpose.  Although, I am pretty certain that these passionate people didn’t just share a common purpose – it meant everything to them.  And so, to all these wonderful people who gave up their time so we could learn a lot more, take a huge bow.  You deserve it! (PS: Can’t wait for next year!)  And if you’re looking for copies of the slides, then hop over to this page.

A few personal observations about this event:

• smooth! very, very smooth!
• Excellent speakers, excellent content, great questions.
• Nice buzz.  Felt like there was something for everyone – from noobs to old war horses.
• Adoption Challenges!  Seemed like this was a topic that came up in various guises during the day.
• Sharing.
• The magic wand / silver bullet was not in the building.
• Professional event with a warm community feeling.

And a small note on my presentation since I heard the comment “So what’s agile design got to do with Scrum?”.  Short answer: everything!  Absolutely everything.  If you’re using Scrum do build software, then agile design is the best feedback loop that you have.  The fact of the matter is that code does not lie yet it is the most ignored area in Scrum.

Well, I thought it was ignored until Jeff Sutherland, in his keynote, answered that Scrum hands off all agile engineering practices to Extreme Programming.

And read what others have tweeted about #scrumdaysa!