f3yourmind

Do you remember that catchy Beatles song?

Oh yeah, I´ll tell you something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand

So what made me think about this?  That frustrating construction of the new M5/N1 interchange in Cape Town!!  When you’re sitting in traffic, you can’t do anything but look and think.  And I’ve seen this scaffolding get taller and taller and wider and wider and longer and longer and more and more people appear on it each day.

Sourced from http://www.capetown.gov.za

I know that one day, they will remove the scaffolding and the concrete will just hang there in mid air on those massive pillars and walls that they’re busy building, and I won’t be sitting in traffic any longer, and it will all just work.

What a shame that software is not like that !!  So many people get turned on by scaffolding.  And The Beatles sang on …

And when I touch you i feel happy, inside
It's such a feeling
That my love
I can't hide
I can't hide
I can't hide

And just like the M5 construction, so much scaffolding gets built, and so many people climb on.  But then, they don’t climb down.  And they don’t tear down the scaffolding.  And it just stays there mashed in with the concrete bits.  And then they ask people to use it.  And it takes strain and then it’s a performance problem, or a load problem, or it just crashes down.

I do use scaffolding, but most of the time it’s in a spike and more often it’s in a test, just to get me over my point of fear.  Deploying software with scaffolding is just dangerous and negligent.  I really don’t want to drive my car over the M5 interchange while those thin steel pipes are holding up the concrete slabs.

But above all of that, the most important scaffolding is social scaffolding.  It’s better to provide human scaffolding to support each other on a team that is focused on delivering quality software.  It’s worse to plug in weak struts in the code base that will just collapse when the next developer builds on top of it.  Very un-ubuntu!

So, the Beatles song still holds true, but only for social scaffolding.

Yeah you, got that something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand
I wanna hold your ha-a-a-a-a-a-and

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.

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.

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.

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.