f3yourmind

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.

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?

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.

A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications.  They’ve also chosen cucumber as their acceptance testing tool.  All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle.  I think I’ve spotted the reason for this.

The feedback loop is missing.  They view the stories as a spec that has been handed down.  And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain.  It is a form of writing code.  But it’s just that this code is, maybe, non-executable.

Here’s my workflow and how I close the loop.

• write story and scenario
• Sketch a design if needed – helps when pairing to be on the same page.
• Start writing test for scenario
• ooops … test is getting complicated? stuck?
• maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
• or maybe the scenario was badly written? Ignore scenario structure, continue writing test.  Refactor scenario later.  We’re in deep discovery mode here.
• get test to pass
• refactor code
• refactor scenario
• … cycle the red-green-refactor until happy.

Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick.  Nothing is cast in concrete.  That’s why I like frequent feedback loops with tight turning circles.

No feedback loop, no progress.

BTW, I really don’t like explaining such things as flow-charts and sequences.  You got to find your own style.  It’s not a recipe or rules thing.  The above is something that is about as close to what I do but it changes when the need arises.  That’s also another key feature of being agile – adapt or die in the waterfall.

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.