f3yourmind

Metaphors may be a good way of getting to grips with a new domain.  It allows you to imagine the behavior of something that you don’t quite understand (yet) in terms of something with which you are quite familiar.  That’s were it should stop. I hate metaphors that extend beyond their purpose.  Once I have a good enough understanding, I drop the metaphor.  My reason is simple.  Metaphors force me to do a lot of energy sapping context switching.

Technical debt is one of those metaphors that have been extended so far, that it is believed by many to be something tangible.  Let’s get real here:  Technical debt does not exist.  It is just a metaphor for us to realise that our code base may cost us more money than it should, and that is a future view.  Sometimes our metaphors become euphemisms, and then it is dangerous.  When it comes to technical debt, the less I think of code problems as debt the more I am able to face the problems head on.

Ironically, I did a talk recently on dealing with technical debt.  My fundamental position is simple.  Either your code base has things that exist as a result of broken principles or it does not.  The more principles you break, the more potential problems you have in your code. It is not a problem right now, but it may be a problem in the future.  This future can be a minute away when I run my next test or a year away.  If the future is infinitely far away, then it is not a problem at all.

My first prize is to not break principles, so I don’t create potential problems.  My second prize is to deal with real problems and just leave the potential problems for the future.

(Warning: I’m drifting into my enlightenment self-reflection, so feel free to stop reading now.)

If I am part of the exploration that is looking for a solution (living in the moment and not outside it as an observer), then I should be aware of principles that I am breaking and I should change course immediately.  If I am part of the exploration that is dealing with the potential problem that is now a real problem, than I need to understand the principle that was broken and fix the problem by restoring the principle.  Restoring the principle could mean going on a search for the right solution to the original problem, not just trying to fix the problem that is a result of breaking a principle.  This problem that broke the principle may just be the wrong solution that we thought was the right solution because we ignored our principles in the first place.

Hmmm, that’s an interesting thought.  Karen Greaves asked me if a re-write can be justified and I mumbled something about technology, etc.  What tripe!  Now I think I’ve just reflected on when a rewrite is justified.  When refactoring will not fix the broken principle, then the right solution was never discovered in the first instance.  That is also what I mean when I say that clean code is necessary by not sufficient.  At factor10, we call this a radical makeover.  Radical makeovers are a viable way of getting rid of real problems, and restoring principles.

Heck!  This blog post is less about technical debt metaphors than I thought.  Oh well, the ride on this journey never stops.

By the way, a huge thank you to Steve for helping me realise that all problems come from breaking principles, in code and in life.

Jimmy Nilsson asked me in an email a few days ago “How’s life?”.  I’m sure it was just a regular, friendly question, but I gave him a “life” answer.  It was not spontaneous but something that has been brooding in me for a while.   It is about things that I have been trying to do for a long time.

Here’s a few splintered thoughts from my email exchange.

• Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
• There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
• Code from my heart because I should trust myself first.
• Be part of the exploration, not just an observer.
• This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
• Passion is constant whether I succeed or fail.
• Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
• The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again

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.

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

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

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’ve been thinking about Cloud Computing over the past few weeks.  And the business of Chunk Cloud Computing makes me feel more comfortable than the various “definitions” for cloud computing that is out there.

It amazes me that we, as an industry, find it so hard to converge on common ideas.  So, I’ve tried to formulate my own understanding of cloud computing.

I think it is …

• a very scalable hardware platform that you share but don’t own
• an infrastructure service that you use but never maintain
• a computation environment that scales when you scale
• data storage that is distributed but consistent
• about writing applications that wire up highly cohesive, loosely coupled chunks
• about freedom to choose and change but with greater responsibility and consequences

The last point was enlightening for me.  For sure, some vendor will pitch the “Lower your future running costs” line.  But I think Future Running Costs = Zero.  You never plan for the future but only for what you need right now.

Wow!  that is so Zenful.  Cloud Computing is about living in the moment, all the time.