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.

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 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.

Here are some choice bites for ubiquitous language.

“They have been at a great feast of languages and stolen the scraps” – William Shakespear

and

“Thought is the blossom; language the bud; action the fruit behind it” — Ralph Waldo Emerson

And on the need for simplicity, I really liked this one.

“There is never any justification for things being complex when they could be simple” – Edward de Bono

Robert Bravery commented on an old blog post of mine and I re-discovered this one

“Don’t indulge in any unnecessary, sophisticated moves.  You’ll get clobbered if you do” – Bruce Lee

Lastly, and the one I’m definitely going to use to stress the importance of working directly with the domain expert.

“Never hold discussions with the monkey when the organ grinder is in the room” – Winston Churchill

What a diverse group of people but such collective value.  Do you have any classic quotes?  Obscure quotes?

June: Next week is SPIN week.  Join us after the June 16 public holiday.  Same time, same place.  Last month we had 40 people attend and we just about ran out of chairs.  Lots of new faces.  Please come along.  The talks are normally good and the conversations are great.

July: Really need to get my act together and get to the next SA Developer’s talk.  Hilton Giesenow tells me it’s a great local event.  And On July 27, Lia turns 5!  Simply amazing!

August: Hmmm, seems quiet?  I think I’m going to submit a tutorial proposal for the ICSE conference happening in Cape Town in May 2010.

September: Looking forward to the Scrum User Group’s conference in early September.  I may be giving a talk on the techie track.  I think it’s going to be a great event.  Carlo and Peter tell me so.  But on September 3, Fiona turns … older

October: My tutorial on using DDD and AOP to create clean, rich domain models has been accepted by OOPSLA.  So, October is OOPSLA time for me.

November: I will miss Oredev.  The competition to get in was so much tougher.  That just means it’s going to be better than last year.  If you’re a S.African developer, you should make a plan to get there.  It’s a great event that is very high on value for money.  But my November highlight is Khaleel turning 9 on the 22nd!  Boy, how did that happen so fast?

December: Crazy season again.  I really hope it’s a quiet, relaxing one this year.

A few weeks back I got invited to Gatorpeeps by Stii via a tweet dialog that we had.  Didn’t know much about it but dived right in.  What a great surprise.  Although I only have 10 followers and less than 100 peeps, I found the community  humble, friendly and relaxed.  What a pleasure.

It reminded me of the pre-Internet days when everyone on a BBS at the slow end of a 9600Baud Hayes (in)compatible modem was just there to help each other out.  No showboating, no egos, just people interacting with people.  It felt good then.  And it feels good again.

So what’s wrong with twitter?  Nothing.  But these are local folk with local perspectives which makes it easier to relate to and quicker to build relationships.  Hey, I’m certainly not a big mate of any of my followers but it feels comfortable and that says a lot about what Afrigator is doing right.

I’ve met some remarkable people in the last few weeks.  Here’s just a few of them.

@ashraf runs a super cool football fanzine.  Why go hunting for footie gossip when I get a peep feed .

@aegjung is an interesting combination of Afrikaner philosphy and culture and alternative views of things.

@cntombela has a another great footie blog with local flavor too.

@justinhartman is the open face behind Afrigator but his blog is a lot wider than his job

@robertbravery gives me a quick daily dose of web content/tech knowledge.  Short and sweet.

@stii is a developer supreme at Afrigator and his blog is a mixture of developer experiences and observations.

Go on, get your blog onto Afrigator and start peeping.  You’ll be surprised how many people like you are out there.

Like I said … if you ain’t on the gator, you ain’t in africa.

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.

What were they actually doing? They were mapping the client’s domain to the reference architecture domain and thereby identified reference architecture services that supported the client’s needs.  This most probably works for some people.   But I feel uncomfortable with it because…

• It means translating from one domain to another and back again.  It’s like having one massive bounded context around the reference architecture with a gigantic set of adaptors and transformers.
• There is a very real possibility of semantic impedance on the boundary of the two domains.
• There is likely to be two domain vocabularies or one large polluted vocabulary with synonyms, etc.

There are other reasons but these few are just old problems and habits coming back again.  Things that we accepted as dangerous and limits success in creating good software.

So, are reference architectures bad? Yes and no.  Maybe you should consider adopting its domain vocabulary as a first step.  A reference architecture with a rich metamodel is more likely to be more valuable than one without a metamodel.

And the moment you start thinking at a meta level, then you’re moving into a higher level of abstraction.  In this higher level, you will have a greater opportunity to describe your intentions agnostic of the reference architecture and the vendor’s technology stack.

The way I see it, services are defined at a meta level.  They describe your intentions and are independent of a reference architecture.  However, if you chose a reference architecture up front, then describe your intentions in the vocabulary of the reference architecture.

Does this make sense?  Because I’m just hypothesising here.

I think I am actually searching for a muse.  Something that will be my creative genius.  I gave up trying to be a genius a long time ago.  Now I just want to learn from those that are better than me, whatever the context.  Maybe my muse is the sum of every engagement with the genius in each person with whom I work and live.

But I think the main reason for pilots and proof of concepts is to get feedback.  Spikes do the same thing too.  You know you’re seeking enlightenment when you start saying “I don’t know … enough…” or “It depends…” or “What if.” Whenever we work with a new domain or a tricky part of an application, we are searching for feedback, not miracles.  If you practice TDD and do exploratory testing of concepts that are not 100% clear in design and even understanding, then you know what I mean.  Perhaps we must just drop the grand classification labels and our response should be something like “Well, let’s explore this tiny bit and see what happens” or “Why don’t we try out this idea by doing …”.

So we do proof of concepts and pilots all the time.  It’s just that I hate searching for miracles but I like feedback which helps me change the probabilities of certain of things happening.  And I like it to be part of my workflow.  Exploration gives me feedback and increased understanding that leads to more exploration.  I hate it being a milestone on a Gantt chart and when that milestone is a common point in critical execution paths for the project, then I know, for sure, someone was actually looking for a miracle.

If you are somewhere on the agile adoption curve, then drop the Gantt chart.  Now you’ve just removed the shrine for miracle worship.  There are no shortcuts to enlightenment, just feedback with every step.  Success depends on how you absorb and react to that feedback.