Monthly Archives: December 2013

Inverting Traditional Approaches to Teaching TDD: A Ridiculously Small Step to Build the Habit

Recently I had a conversation with Ingmar van Dijk who is one of the most talented technical coaches out there, and we were discussing how we can do best for our clients in our testing and refactoring classes.  More specifically, we had agreed that most of our clients are not working on green-field codebases and although learning testing and refactoring skills is a good first step, it is not enough to really tackle the hard problems.

We were discussing how mastering TDD, and making it an everyday habit was a multi-month process for both of us from the moment we were introduced to it, until the time we had the skills and abilities to actually perform TDD on all our code.

And we agreed that this probably one of the major reasons that the technical practices like TDD and BDD are not as widespread in the community.  They are difficult and that impedes them “catching on”.

Ingmar had suggested the idea that we start with the skills needed for working with legacy code FIRST, and then perhaps go back to the intricacies of TDD and refactoring later.  It seems like putting the cart before the horse….   But after a couple of weeks away from the conversation I think he is right.

Think about it – one of the reasons we don’t build a habit is that we don’t have the ability to do TDD on all our code after we are introduced to it.  So it is hard to pick one regular trigger.  But what if we learned a few micro-skills that would allow us to work with existing code first.  And then AFTER we built the habit of writing (very simple) tests for our code before we touched anything, THEN we came back to honing our TDD skills.

This would mean, we would start with:

1) Breaking dependencies in existing code,

2) Creating characterization tests,

3) Build the code in a test-after method regularly.

Then, after the habit is built for testing all code that we work on, we go back to test-first development and refactoring and refine our skills?


Posted by on December 29, 2013 in Uncategorized


Tags: , ,

Test Driven Development and Habits

Habit-forming is my new (short-term?) obsession.  And I’m looking back at some of the practices in agile development and what I can learn from the habit=f(motivation, ability, trigger) equation.

Technical practices – test first development, refactoring, requirements driven development, etc…,  are some of the most valuable practices in our toolbox, yet, unfortunately are the least commonly practiced.  We all know that they are difficult – but is that enough to keep us from doing what we know to be the right thing to do?

The motivation is usually there to certain degrees.  In fact, looking back, the most successful teams are those in crisis and they have really serious motivation to help them go through the huge learning curve (i.e. ability in habit-speak).

And the triggers are pretty simple – write a test before you write code.  Write an acceptance test before you start the iteration.

The real problem here is the ability – it is a really high bar.  If we remember that ability needed and motivation required are proportional – then we need to bring the ability needed down so that you don’t need great motivation.  Here’s what we’ve tried so far:

  • immersion classes (in the early days of eXtreme Programming)
  • training classes
  • eLearning (such as Industrial Logic’s technical albums)
  • mentoring
  • coaching
  • pair programming
  • katas
  • etc…

But the fact is, those things reduced the hurdle, but evidence shows it is still too high.  So, I’ve been thinking, “what ridiculously small steps can we take to help people build the habit first?”.

And since I am currently writing in ridiculously small steps to build my own blogging habit, then I’m not going to worry too much that I don’t have the answer now.  But I think I have a really good question.  And I’ll let my subconscious work on it for a bit and blog ideas as they come up.

But please, if you think this is worthwhile – think along with me.  What ridiculously small steps can we take to make the technical practices habits with more teams and individuals?

Leave a comment

Posted by on December 27, 2013 in Uncategorized


Tags: , ,

An Experiment in Habit-Building

I have a theory that I want to test out and would like to invite you to come along for the ride.  I want to blog more regularly.  In fact, I want to create a habit of blogging – I have wanted to do such a thing for multiple years (maybe you have too?).

The theory is based on someone else’s theory on habit building: Habit = f(Motivation, Ability, Triggers).  What’s cool, is that Motivation and Ability are proportional.  That is, if you are trying to build a habit for doing something trivial, then you need very little motivation; all you really need is a trigger.

So, how do you do something trivial?  Take a ridiculously small step.  Ridiculously small is in meditating for 2 breaths, doing 2 pushups, or ….  Or writing 2 paragraphs and blogging them.  Just two paragraphs.  No reviews.  No agonizing on whether this is the right thing to say or how dumb I’ll look to the reader.

So here we go.  This is the first such blog.  And my trigger will be writing before I go to bed.  That’s it.

Leave a comment

Posted by on December 26, 2013 in Uncategorized


Tags: , ,

Estimates Are Always Low and Dates Are Not Met

Estimates are always low so dates are not often met.  That is a common occurrence in today’s software environment.  There are many, many approaches to this age-old question.  Relative estimation, no estimation, ideal days, and some fancy-shmancy techniques that are mathematically sound (given a few unsound assumptions) that are significantly impressive to those so inclined.

Whatever technique teams choose, they are often still disappointed.  So what gives?  Is there a practice out there that can save us?  My answer is both yes AND no.

The no part is easy. No, there is no one practice out there that can give us accurate estimates. Estimation is fortune-telling.  And all fortune-tellers (at least in software) are wrong.  Estimation is a lie.  Pure and simple.  But it is a very useful lie, because it really helps to have some indication about what and when we’ll get things done.

The yes part is a little bit more involved.  And it comes at the problem side-ways.  Instead of considering the estimation practice itself, let’s take a closer look at how teams typically fail with all estimation techniques – and then address the commonality instead.

Choose any single technique out there.  Whether it is relative estimation or anything else, there is a really good chance it is not just marketing fluff or bullshit.  In fact, there is a really good chance that some really smart effective people used it successfully and have probably helped others use it successfully also.

So what gives?  Why were these techniques successful in some places and unsuccessful in others?  Well, there could have been many reasons, here are some of the most common ones:

  • The original context was different, and it needs tweeking for the current context,
  • The technique was modified because it didn’t “fit” into our context, instead of trying to take the (usually negative feedback) and change the way we work,
  • We weren’t very disciplined in using it, because it was too hard, (check out We tried baseball but it didn’t work)
  • There were significant failures, and instead of taking that as a sign of the method giving us feedback, we took it as a sign of the method failing,
  • etc…

So let’s get back to yes, these methods actually work.  What I’ve found, again and again, when it comes to estimation, is that we are not able to effectively manage our agreements around how we will estimate and manage those estimates together.  We are not able to handle failures when they happen.  We are not able to confront issues when they arise.  We are not able to be disciplined in what we do.

These methods, like any methods, can be seen as agreements made amongst team members about how they will work together.  So if estimates are always low, then perhaps we need to look at our agreements; especially those we have broken.  And, perhaps, there is a reason that we are constantly giving low estimates.  Here are some of the ways some of the invisible impediments get in the way:

  • Safety:  Perhaps the #1 culprit when it comes to estimates.  If I don’t feel safe giving what I *really* believe something will take then you won’t get a good estimate from me.  If I don’t feel safe calling out an unreasonable estimate early – then there will be a problem.  And, perhaps the most common instance of all, if I don’t feel safe to say “I was wrong, I need more time” early on – then I’ll just soldier-on.
  • Respect:  Many times we don’t respect each other.  Take the common “Us vs. Them” mentality that is so prevalent in today’s business culture.  If the “Us” is managers, and the “Them” are developers, and we see them as incompetent, they will get that.  They will probably see us as being unreasonable and not able to understand the intricacies of software development. They will also act accordingly.
  • Ownership: Do we have a mentality of a whole team?  Do we have a shared task that we cannot complete alone?  Is our mindset that of “I own the results”?  If not, then it is all too easy to be in an obligation mindset and do estimates a year out because “you HAVE TO”.  And if you do that, then you disconnect from the results and can easily convince yourself “well they were asking for something unreasonable anyway, so I gave it to them although I KNEW it was the wrong thing to do”.
  • Intent: Why are we REALLY doing estimates?  Is it our intention to just get the managers off our backs?  Or, as managers, is our intention to hold people accountable (and even CYA?) if things go wrong even though we know estimates are a fiction?

So, if we are doing some sort of estimation method and it is not working, perhaps we need to look at the team dynamics.  Perhaps we need to look at how we work together as a team around our agreements.  And perhaps we need to look for some of those pesky invisible impediments and start on fixing them first – BEFORE we look at the estimation methods themselves.

Leave a comment

Posted by on December 16, 2013 in Culture, Organizations, Teams