Rolling out a methodology is about design

Implementing a new methodology is a painful exercise.  Lots change, lots break, and lots of so-called “colateral damage”.  I have tried implementing new methodologies including XP and Scrum many times.  I have also witnessed a lot of attempts by other people, and been involved while others drove the initiative.  Every time, it has lead the organisation into a disruptive, stressful state.  The most common position taken by the implementors is:

Of course it is disruptive.  That’s part of the change-process.  We all knew that from the moment we started. How else do you think it’s going to get better?

In the past, I’ve been guilty of the same.  The end result is that I am left unsatisfied and unfulfilled, and so is the organisation. Yes, it may eventually get better.  Eventually I got sick of taking this high road.  Well, it only took two such situations a long time ago to realise that I was messing up royally.

In my quest to do things better, I drew inspiration from test driven development and dealing with old, messy legacy code.  Three very distinct things which are rooted in software development and changing legacy code is very, very apt.

  1. Rolling out a methodology is at the implementation level.  So, was there a design for the implementation in the first place?  Implementation without design always ends up in a mess.
  2. Even if we abstracted the design from one implementation, does the design support all implementations?  “Similar” does not equate to “same”.
  3. The existing methodology has a set of protocols by which the organisation functions, while the new methodology introduces a new set of protocols.  Just dumping down the new protocols is the equivalent of rip and replace – the grand rewrite without care for migration.  Is this the only way?

So, taking inspiration from code, here is something that you can try when attempting a new rollout.

Understand the existing implementation. Use a test based approach to concretely discover existing protocols within the organisation.  This may be as simple as playing out what-if scenarios that test the communication pathways.  Keep your eyes wide open for seams or boundaries.  These seams are candidates for incision points for introducing a new protocol facing in towards the area under change while honoring the old protocol facing out towards the other side that should not be changed (yet).

Design, design, design. Once you understand the existing protocols and how they behave under certain scenarios, you switch to design mode.  Look again at the dependency graph within the organisation for a particular protocol.  What is affected when a certain event occurs?  Then look at your candidate seams and incision points and design your wedge.  It may be a transformer that completely modifies information as it crosses over the seam.  Maybe it’s a buffer with a finite capacity that slows things down and trickle feeds info to the other side.  What about a filter that removes some info?  How about something that just decorates existing info with a just a wee bit more that is tolerable on the other side.

This design is mostly about designing feedback loops.  As such, you need to consider the temporal and synchronous aspects of feedback also. What is the expected latency when I stick in this new wedge?  Will it take one week or one day or one hour when something crosses this boundary?  Do we send off some info and wait for a response on the same pathway, or do we get informed of which other pathway to regularly check for the response?  Perhaps someone gets nudged when the response arrives.

Implement it test first. While it may seem like a lot of upfront work is necessary to get the ball rolling, it can be done in tiny steps.  You don’t need to fall into the analysis hole when looking for seams.  Nor do you need to get stuck looking for the perfect design.  It is better to remain concrete for long periods of time, than speculate at possibilities.  Doing a little bit at a time with some small tests helps you keep both feet on the ground.  For example, you want to switch from the old protocol of reporting progress with budgeted vs actual to burning down story points.  Some people still need to use the budget vs actual report and it is inefficient to have to maintain both (not to mention not DRY at all).  We need a way of transforming from burn down to budget vs actual.  Think about candidate tests that will shift you towards that goal?  Maybe it’s “I should be able to take existing budgeted tasks in a time frame and map it to tasks on the burndown”.  Perhaps it is “I should be able to introduce new time frames on the budgeted vs actuals that synchronise with new sprint boundaries”.

These are just some things that I think and try out.  It comes from me being sick and tired of subjecting people to stressful implementations and being party to messed up implementations too.  It’s just too easy to blame someone or something else for our own ineptitude.  I don’t take the high road anymore.  I take the middle road.  It doesn’t travel straight, and has branches with dead ends too, but it leaves me a lot more content.

You can’t let Scrum die

In my last post I said we should let Scrum die.  We can’t let Scrum die.  It doesn’t behave like that.  It will only die off its own accord if we die first and then it dies because it has no reason to exist.  So you got to kill it.  Here’s why (again?).
Software development is about people and the way people work alone and together.  People create code in software development.  Without that code, these people don’t exist; they have no purpose.  Code is the creation of the people, and people live off this code.  When the code is good, then life is good.  When the code is poisonous, then people start dying slowly.  When the smell of death is in the air, they look for help.  Some stare into the mirror called Scrum. They see themselves and the way they behave.  It’s an ugly sight.  They realise that they should behave better.  After all, software is about the way people work alone and together.

Regularly looking into the Scrum mirror, they improve their behavior over time, and everyone is happier than the moment before.  That’s a nice view.  Just look in the mirror and it looks good.  Very rarely do they also look again through the window into the fields of code that feeds them.  The poison is still coursing through their veins.  They will die, eventually … by the host that they created that was supposed to nourish them.  The only way to survive is to deal with the fields of code.  Get rid of the toxins.  There are two fundamental ways(*) that you can get rid of toxins: (a) eliminate duplication, and (b) make the code as you wish it to be.

If they just stare into the mirror and hardly ever look out the window, they will just exist on the plateau of complacency.  In order to avoid that state of being, they need to focus on the fields of code.  The urge to look in the mirror is strong, and as useful as it was, it becomes a very unbalanced state of existence.

So, look in the mirror, but look through the window too.  Create fields of code without toxins so that you provide nourishment for the next person.  That is ubuntu coding.

Actually, the only mirror you need is the person working next to you.

(*) Think deeply about these two fundamental things and try it out.  Everything else will fall into place from this. For example, the act of eliminating duplication forces you to consider where to locate a single piece of code, how it should be used and where it can be used, etc.  That is design and architecture.  With duplication, you don’t need to consider any of those things.  That’s toxic.

A coach walks into a bar …

One day you are faced with a problem.  You succeed or fail in solving that problem.  It doesn’t matter.  Time passes.  You meet someone who paints a picture which has some parallels to what you experienced.  A few possible things can happen.

(A)

You tell them about your experience.  They listen. They ask questions, you answer, talk, listen, listen, talk …

(B)

You ask them a question.  They answer, question, answer, question, answer …

(C)

You chat.  It is not anything like your problem.  Chat, chat, chat …

Given each scenario above, when are you a coaching?  When are you being coached?

My view on coaching is simple.  We oscillate between knowing and not knowing so often that it doesn’t matter who is learning from whom.  It does not matter !!  In any given context, you are either a coach or being coached based on what you know.  You fluctuate between these extremes many times in a conversation, in an hour, in a day, in a lifetime.

This is part of my quest for balance through the work that I do.  “Coaching” feels one directional, a fabricated “us and them” labeling of people. That is an unbalanced state of being.  Learning is a balanced way of living.

And if you have not yet figured it out  … agility is about learning, learning is about living, living is about being in the present, being in the present is about embracing change, embracing change is about being agile.

What freedom?

At the Scrum gathering I had a tiny little conversation with Lorraine Steyn of Khanyisa Real Systems and Henrik Kniberg of Crisp about some of the values in our organisations.  At the top of Henrik’s value list was Freedom.  It seemed straight forward enough, until I started thinking about what freedom means to me.

My early perspective and experience on (the lack of) freedom is based purely on oppression of apartheid.  Ok, that’s over, so I am now free. Right?

Then John Lennon’s Imagine lyrics sang through my head.  If we’ve nothing to kill or die for, will we have universal freedom?

Hold on, what about when Janis Joplin sang Me and Bobby McGee – “Freedom’s just another word for nothing left to lose”?  That sounds too dreary for a concept that should make me happy.

Tonight I saw a quote by Maria Montessori on the wall next to my wife’s desk at home.  It’s been there forever and it says:

“The  essence of independence  is to be  able to do something for one’s self.”

I like this the most.  Be able to something for yourself and you will gain independence which sets you free.  It also reminds me of the self-organising mantra in Scrum-land.  Self organising implies that the team wants to be able to manage themselves so that they achieve independence (freedom).  But, there is a little spark of conflict in here.  As individuals we also have priorities and values, which is not necessarily aligned with that of the team.  Is it acceptable to compromise just to subscribe to the homogeneity of the team?

I think it’s a long walk to freedom.

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.

Ubuntu Coding for your Friends

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?

Cloud Computing Zen

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.

Zen and the Art of Deck Building

Amazing! I just read Scott Hanselman’s blog post on finding geek balance outside of the geek world.  I started commenting on his blog, but realised I was blogging on his blog.  Here’s my own lumber-yard, geek-balance experience.
Just before Christmas, Fiona and I decided to have a deck built in the back yard.  I tossed the contractor’s quote out and decided to build it myself.  Why?  Same reason as Scott and I also specifically wanted to try my own personal Zen and the Art of Deck Building.  Fiona was naturally skeptical but indulged my mid-life crisis moment.

An apprentice in a world craftsmen.

DIY shops are intimidating.  I was an apprentice in world of journeymen and craftsmen.  I eventually found a benevolent craftsman who was humble enough to help me without judging me.  His ideas helped me simplify my design considerably and, more importantly, gave me some confidence.

Really listening to feedback. My paper design was a BDUF :-).  The moment I placed the wood on the ground, Fiona suddenly changed the location of the deck.  Short tale:  I am still building – new requirements still emerge from my main user.  Early on, I resisted every change with enormous annoyance which resulted in huge arguments.  Then I realised that the needs were real and the new requirements came from seeing how the deck looked with each step of construction.  I had an abstract BDUF and Fiona was taking in real feedback –  being agile!  And I was being rigid!

Living in the moment. I tried hard to live in the moment.  When I was digging a hole, I dug the best hole ever, deep, straight and true, until I hit a concrete block in the way.  Then my beautiful hole was a mess and I was angry at this block and tried to get past the block and continue digging my hole.  Zen moment – the task had changed.  I focused on the concrete block. Chipped away one tiny piece at a time, eventually it fractured and I could continue digging my beautiful hole.  I was focusing on the future, not the present and that screwed up my productivity.

Conflicts in collaboration. So I tried to live in the moment with everything from that point onwards.  When I was cutting wood – I cut wood and tried to get the best cut ever – to find beauty in the cut.  The one day my son, Khaleel, helped out and I got annoyed that he was messing up – it was not as beautiful as I wanted it.  After calming down and living a moment of fatherly guilt, I let him help me dig another hole and I just let him … to live in his moment.  He loved the texture, smell, etc of the sand and dirt.  I imposed my own hang-ups of not wanting to get really dirty.  I realised that he was more into having fun and I was messing up his fun – until I decided to live in the moment with him – by his values.

Finding the balance. Building the deck has been one of the nicest non-geek experiences in recent times.  It made me think differently, behave differently, regard people differently and maybe, one day, it will quietly help me build software better.  I think the trick is to find a place where you will always be the traveler in a world of benevolent journeymen.  And when you can’t find that world, then just be a benevolent journeyman in world of travelers.

Coding for Enlightenment

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 🙂

Technical Debt Does Not Exist

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.