Test First TDD

I think that TDD is getting bastardized.  If you happen to use a Unit testing framework, it does not mean that you are test driven at all.  TDD is about test first to drive the rest – design, clean code, feedback, quality, and lot more.  Using a testing framework is easy.  Being test first driven is really difficult.  You may start off with the mechanics and focus on the cadence, but you only feel the value a lot later – when you have woven it as an attitude into your fabric of thinking.
That’s why I’m giving the TEST FIRST TDD course next week.  If you want to go beyond just learning about an xUnit API and step on the path of a personal journey to changing the way you create software, then come along.  I don’t have miracles but I can do better than just shining a light.  I will step into the darkness with you and help you move towards the light.

Mapping Steve’s Mind and More

If you hate reading lengthy blog posts and dig the mind map view of the world, then add Steve van der Merwe’s blog to your feed gadget.  What I really like is his short quick observations and great views about software development.  But for me, it’s even better that I get to speak to him regularly, in person.  If you’re in the Cape Town area, make a point of finding him and chatting to him.  He makes ubuntu real.

DDD Reference Card

I know it’s absolutely insane to try to reduce Eric Evans’ amazing book into just a few pages, but stupidity won.  I think it’s still useful as a “next to the coffee mug on your desk thing” if you’re just starting off with DDD.  So download the free Domain Driven Design Reference Card at http://refcardz.dzone.com. Small warning: it’s not useful unless you’ve read Eric’s and/or Jimmy’s book or have attended a DDD course.
I’ve tried to keep it true to the book.  I’ve aslo added a reference to a couple of additional patterns right at the end, after some quick chats with Eric and Jimmy.  Given the space constraints, I decided to leave out the CQRS work.  It feels better anyway, since this meant as a cheat sheet for people starting out.

Gotcha! (side-effects really pain a lot)

I just upgraded to Snow Leopard and installed buildr which failed miserably.

/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: dlopen(/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle, 9): no suitable image found. Did find: (LoadError)
/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: no matching architecture in universal wrapper - /Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle

It turns out that I needed to rebuild rjb, the ruby-java bridge, but that failed too.

extconf.rb:48: JAVA_HOME is not set. (RuntimeError)

I was certain that JAVA_HOME was definitely set and it was pointing to the 64-bit Apple 1.6 JDK.  Digging in extconf.rb, it finds JAVA_HOME from the ENV hash

javahome = ENV['JAVA_HOME']

So, nothing weird about that too!  What’s going on?  I was installing buildr like this

sudo gem install buildr

The problem is that once you sudo, you are running with another environment, one without the JAVA_HOME variable.  So, the quick fix is simply

sudo env JAVA_HOME=$JAVA_HOME gem install '1.1.9' rjb
sudo env JAVA_HOME=$JAVA_HOME gem install buildr

I completely forgot about this side-effect.  Like all side-effects, it was painful – it just cost me an hour of  digging around looking at all sorts of other things.  But, more importantly, breaking fundamental assumptions (e.g. my environment is the sudo‘s environment) and zoning in on the root cause of the problem resulted in a very simple solution.

Forced compliance is an obstruction to discipline

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.

Readability is the real (re)usability

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.

There are no boundaries, just forces

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.

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.

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.