Are you coming to OOPSLA?

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.

Driving through a red light can kill you

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 …

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.

Scrum Day: Happy, Tired, Inspired

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!

Life Agile: Being a Father

I often talk about fake agility – agility in process and not in your mind.  And I nauseatingly tell everyone that if you want to be agile, you must become agile in your life.  The one area that I’ve been struggling with for almost nine years is fatherhood.  I don’t think there is a tougher learning ground for agility than being a father (of course, Fiona will tell me that motherhood is a lot harder, and she’s most probably right).  But after just under nine years, I still feel like a beginner on the Dreyfuss scale.  I do look for signs and feedback and adapt to parenting situations on demand but the unpredictability of being a father is undeniably higher than any software project I’ve worked on.  The reason is simple: children are naturally agile.  They react to their environment instinctively, doing what makes sense to them.  In spite of being aware of agility, the theory, the principles and practices and being a practitioner for so long, I am convinced that agility in fatherhood is a significant step in life agility.
To help me progress beyond “Beginner”, I invited some friends to write a short piece on Agile Fatherhood.  Each one my guests has either just become a father for the first time or been “coaching” for a few years now.  I left the interpretation of the topic up to each person.  Personally, I think it makes for some fascinating reading.  And if you know these amazing geeks, you will learn a more personal side of them and understand them just a little bit more.

So here are some thoughts from friends much wiser than I and for whom I have an immense amount of respect.

claudioClaudio Perrone ( Oh man I hate you 😀 )

Being only one month on my first baby boy I feel I’m not even chartered in the Dreyfus model, so I’m not sure I have much experience to share yet 😀

Being agile means to be able to quickly adapt to change, not simply react to it. Irene and I have struggled a lot. Then something happened. Instead of reacting with frustration to an ever screaming baby (I still call him the Anti Christ 😉 I began to fully accept Matteo as an individual I needed to understand better. I “reprogrammed” my tone and attitude. I read a book on newborns. Apparently I have a “touchy baby” (aren’t they all?). So was I apparently. My mum told me that, exasperated, she once brought me to the doctor asking “what the hell is wrong with him???”
Among other things, I took ownership of the kitchen (i had to) and bought a book to try many new recipes (I didn’t have to, but I was getting bored of my usual pasta).

Finally, in the last few days, I dropped my usual bottom-up GTD approach to productivity and went back to a top down approach. Mission, roles and goals, in other words (or “do the right things before doing them right”). It is still work in progress, but the sudden imbalance forced me to revisit my roles as family member, friend, self (to eat better, exercise, learn and refine my skills), my impact at work (ahah currently none), my contribuition in the community and, finally, how I can still relax and enjoy life. (if you are curious, I’m  experimenting with Life Balance for the iPhone – Omnifocus is suddenly sitting idle).

If you need only one sentence with an agile perspective:
Embrace change and enjoy the ride. And since you can’t possibly be perfect, strive to achieve instead 😉

niclas-bw_biggerNiclas Nilsson I tweeted this a little while ago, and a lot of people actually found it to be a useful analogy:

Raising a kid is like playing a platform game. First everything is new and a bit tricky, but then you get a hang of it. For a while, it’s actually quite smooth and you start to believe you’re pretty good at it. About that time, it turns out you have completed that level and you’re standing at the gates to the next level. But to get to the next level, you have to pass a monster…

If I’ll connect this to your question, what I mean is that everything seems to go in phases (iterations? at least increments), and that you’ll always get a new challenge (often in surprise) that you don’t know how to handle and you have to resort to your problem-solving agile mind to figure out what to do. Or rather, what to try first, since you have to try and try again until you find what works. If your lucky (or talented? or hard-working?), you’ll find a way that works and avoid screwing them up for life, but you’ll have to wait and see until they become teenagers to be sure. There’s no roll-back functionality in life. You can try compensating transactions, but you can never go back to the exact same state.

Profile_HKHerman Lintvelt Wow! Selected from maybe millions of people… 🙂

Communication; the importance thereof. That is probably one of the main ideas that I am extracting from the Agile approach. One of Agile’s core principles is to place people above processes. That implies that good communication is very important. Part of good communication is regular, positive feedback. So I’m trying to really make that part of my approach towards my two-year old boy. (His sister is only six weeks old now, so communication currently consists of making goo-goo sounds, or sometimes just googling at her). E.g, we are encouraging him to say “please” when asking for something, but recently realised that we are not using “please” when we ask him something. Now I try to lead by example and use “please” and “thank you” when talking to him as well.

I still have a lot of iterations ahead with them both, and I’m excited as well as a bit afraid of everything to come. There is a lot of different “formal” approaches and recipes one reads about for raising children, and I know I won’t be able to follow all of that advice, so I’m just staying agile and concentrating on people above processes.

chris-face_biggerChris Hedgate I really like Niclas’ analogy with platform games. I remember some games where you could move along quite smoothly through a level, save whenever you want and come back later to continue. But then, you go through a door, and you find yourself at the final stage of that level. You are not allowed to save at that stage, so you have to go through it in one try, or start over from that door. That reminds me of how it often feels with my 3-year old now. Sometimes I find myself in a situation that I either have to work through, which often requires lots of time and energy, or just let it go and come back to it later. I used to do this wrong I think, where I would try working it out but not have enough patience or time, and all of that work was lost. It’s the age old saying, “You can’t be efficient with people”. So I think that is one thing that connects work and fatherhood for me, always deciding if it is the right time to pursue some goal or try to make some change happen.

For me, the most important parts of agile is people-focus and constant learning. And I definitely bring both of those to fatherhood. Like Herman said, communication is really key. It is amazing what a 3-year old can tell you if you really ask, and understanding their reasoning will often show you that you are trying to “fix” something completely different from what the problem really is. And there’s where the patience and time comes in, you cannot rush this communication.

Regarding learning, I believe life is a long continuous learning experience. So therefore I encourage my son whenever he is interested in something. Right now he is into dinosaurs, so we talk a lot about dinosaurs, look at pictures and so on. He can name Tyrannosaurus, Brachiosaurus, Anchylosaurus, Stegosaurus, Triceratops, Pterodactyl and probably a few more from seeing them in a picture.

Regarding Claudio’s comment about retrospectives, I think even if you do not have formal retrospectives it is a great idea for both mother and father to observe and discuss each other’s behavior. It is much easier to see or hear things from an observer point. Also, we often find that if one of us do not have patience to continue through a situation, the other one can step in and resolve it.

Finally, to round off a rather long mail, I have to tell a story describing a recent situation. My son has a party whistle, the ones that make a whistle sound and roll themselves out, that he loves to blow. The problem is that my dog can’t stand the sound and tries to bite the whistle, often resulting in pushing my son to the ground and he gets upset.  So, I see him grabbing the whistle with her (the dog) standing right beside. I could have said “Do not blow the whistle here”, but I know how well that would have worked. Instead I asked him what happens when he blows it, and he said that the dog gets angry.  “Then what happens”, I asked, and he answered that she jumps up and pushes him. So I asked how he likes that, and he said that he gets upset and starts to cry. I asked if he wanted that, and he said no.  So finally I ask “What do you want to do then?”, and he says “I’ll go upstairs and blow it”, and goes directly up without blowing it on the way.

Has this helped me?  Yes and no.  Yes, because the analogies and lessons are extremely insightful and valuable. No, because they didn’t have a magic wand cure.  But that’s exactly the point.  There is no magic, just learning and adjusting all the time.  Like I always say: “You need to let it take over your life.”.  When you do, then everything becomes simpler.  Like making that 1px adjustment on the last level of that game or just blowing your whistle where the dog can’t get to you.

Your ESB is going to kill you

Recently I wrote about the fruitless plight of a schizophrenic service.  Now, I think that some of that schizophrenia exists in the ESB too (or is it rubbing off onto the ESB?).  I’ve always felt that the ESB was just another pattern that showed how to isolate things and deal with routing and transformations.  The most common implementation was a messaging gadget with some pluggable framework of sorts for the transformations, and some configurable framework for routing.
With such isolation of parts, it was convenient to not worry about what happened elsewhere when something was thrown to this gadget for processing.  And we started wondering about scalability things and decided that asynchronous was the way to go … disconnected, stateless, etc, all good, well-intentioned things and useful things.

Then the pattern became a product.  And on top of this product we had more products like business process orchestrators or workflow managers.  And below this product we had applications and databases and ftp locations and all sorts of things that catered for every imaginable protocol.  And around all of this we had some enterprise-ish sort of management thing to keep on eye on everything that was happening inside this very busy product.

Then, services moved from applications to the ESB product.  After all, it’s a service and that’s an enterprise service bus, right?  And when the services where moved over to their new home, all the dependencies had to come along too.  And then we started arguing about getting granularity right in the ESB.  I used to just think that the ESB had a proxy of sorts to the service that still was at the application.  Maybe I got it all wrong.

Now this ESB is starting to feel like an Application Server with a messaging gadget, workflow gadget, transformers, routers, protocol handlers.  And some ESB’s have a web server too, since they have browser based management consoles.

Some people also like the idea of a rules engine for their complex domain rules and embedded those in their applications.  Hold on, those content based routers in the ESB also used a rules engine.  Ok, let’s move our rules over to the ESB too.  Cool, my ESB is also a rules engine.

Now, I see people writing the most hellish XML that is meant to do everything from configure routing, define transformations, execute code, persist messages, fire off sets of rules and more.  It reminds me so much of those weird and wonderful stored procedures and cascading triggers that we wrote.  The other day I got a laugh out of a friend when I told him that ESB’s are now DB servers and everyone writes sprocs in XML.

And we tried to do everything in the database server – rules, custom types, defaults, constraints, sprocs, triggers, batch jobs … even jump into a shell and execute something else.  It did not work out very well then.

If I was an ESB, I’d be very confused.  I started life as a pattern with a reasonable implementation using messaging and transformation and routing.  Now all of this.  In fact, I’d be more stressed than confused.

Then again, maybe the ESB is not confused, and maybe the people that use the ESB that are confused.  In fact, if I was one of those people, I’d be stressed too.

Fast Track to Domain Driven Design

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.
The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the coursecourse contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.

zz485d34cf

Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

  • learn more than just another syntax and set of tools
  • write software for large, long living systems
  • increase the quality and maintainability of your design
  • design high quality models and use code to represent those models effectively
  • develop applications with a good APIs
  • add a design edge to your skill set

zz3caeb696

Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the coursecourse contents / should you attend? / register for the course

Pass the Parcel

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

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?

One Hundreth Away from Fame

I read an article on the strength of the Finnish schooling system yesterday.  It’s considered as the best in the world with a 4% variance between the best school and the worst school.  How did they achieve that?  They give a lot of focus on the bottom 99% of kids in the classroom and not the top 1%.
I have a fear that as a community we promote the top 1%.  I hear developers being labeled such as rock stars and ninjas.  It’s no different to junior developers and senior developers.  We find all sorts of measures to be in the top 1%:  Twitter follower-count, Facebook friends, LinkedIn connections.  I think such labels and measures create an air of exclusivity and elitism to the detriment of 99% of the people.  NINETY NINE PERCENT !!

My 1% rankings have always been nothing more than a fleeting moment.  Once I won a book prize at school and I got an award for some design in university and meal voucher or two for a job well done.  It was meaningfully great in that context, relative to the others in that context.  But it was perceived as such by a few at that moment in time.

Looking back, I feel sad.  Not because of the scarcity my top 1% ranking, but by the reflection that those fleeting moments did not have lasting value to those that were in that context with me.  I should have made it count more significantly.  These days, I want to do things that touch others meaningfully.  Is my my code worth reading and from which you can learn?  Did our conversation over coffee move us closer to understanding each other?  And I want to be affected similarly too, by 100% of the people, not just the 1%.

Sometimes you’re in the top 1% and sometimes you’re in the bottom 99%.  But you will always be part of the 100%.  I am nothing, yet I am everything.