18 May 2015

Is Predictability Really What We Want?

Predictability in software system delivery is as close to a Holy Grail as it comes in the IT industry. I’ve heard many people stress being able to have a predictable delivery cadence as something valuable to them. As recently as today I saw a reference to “predictability over commitment” on Twitter! But why is predictability so important to so many people?

The people who pay for the software we create certainly want to get away from systems that cost more than was originally expected and take longer to deliver than thought. They also want fewer surprises from defects that show up only when a system is in production use, which require more time and money to fix.

The people who manage software delivery groups certainly want to be able to know how much their teams can deliver over a certain time period so they can work proactively to deal with issues such as training and career development.

7 May 2015

Getting Started with Test-Driven Development - Where Do I Start?

If you have ever built software using a true Test-Driven Development (TDD) approach, do you remember the first problem you had to overcome? Was it perhaps:
Where do I start? What’s the first test?
That’s a very common issue - simply not knowing where to start.

Quite a few years ago, I was coaching at a client in the St. Louis, Missouri area. I attended a meetup of the local XP group and it was a session about exactly this topic. It was being led by Brian Button, and he started by speaking about the blank look that some developers have when faced with figuring out where to start. His exercise was to have us pair up and start building a simple game of Blackjack using only a test-driven approach.

I paired with Brian Nehl, who just happened to work for the Missouri State Gaming Commission. I figured that would give us the upper hand over other pairs. Our platform of choice was C#, although the examples I will show here are in Java.

After a very brief discussion about the rules of Blackjack, we talked a bit about where we wanted to start. Well, we need a Game of some sort, so should we start there? The game will have to be able to compared Hands of cards, so maybe that’s the place to start. But what about players? We’ll need a Dealer and a Player and each will have a Hand.

After perhaps 2–3 minutes, we decided to focus on something more fundamental - the Card. A card would need to have a value, and I believe we even started with the concept of a suit. So our first test was something like:
   public void eightOfHeartsIsGreaterThanThreeOfSpades() {
      Card card1 = new Card(8);
      Card card2 = new Card(3);

      assertTrue(card1.getValue() > card2.getValue());
This test forced a few things. First, the compiler griped that there was no such thing as a Card class. So we had to create that:
public class Card {
That cleaned up the first errors, but now we were told there wasn’t a getValue method in Card. That was our next step:
   public int getValue() {
      return 0;
The compiler errors were gone and we could run the test. Naturally, the test failed since getValue only returned a zero. That’s great… we now had our first failing test!

I know what you’re thinking… WHOA!! WAIT A MINUTE! You just hard-coded a return value just to please the compiler!

Yes. Yes I did. And that’s OK! TDD is all about expressing the desired behaviour using tests and making the tiniest change possible to allow the tests to pass. In a statically typed language like Java, it’s OK to think of compiler errors as a form of test.

But now we needed to make the test actually pass. So, we changed the code in the Card class to be something like this:
   private int value;

   public Card(value) {
      this.value = value;

   public int getValue() {
      return this.value;
Green bar!! Our test passed!

We added a couple more tests like this, then realized that we hadn’t actually done anything with the concept of a Suit (Hearts, Diamonds, Clubs, Spades). We decided to refactor our tests to pull out any mention of a Suit because we simply didn’t need it at that point in time.
   public void eightIsGreaterThanThree() {
      Card card1 = new Card(8);
      Card card2 = new Card(3);

      assertTrue(card1.getValue() > card2.getValue());
We proceeded to write tests that introduced face cards and the Ace. We eventually created the concept of a Hand, and could compare the value of two hands by aggregating he values of the Cards within a Hand.

I believe that was when we had run out of time, as there was only an hour for the coding session. The goal wasn’t to complete the Blackjack game, but rather to get comfortable with starting somewhere.
During the debrief, it was interesting to note that out of 6 pairs, only two started at the same place. Equally interesting was that there was no incorrect place to start!

That was the point of the exercise. If you’re stuck on where to start, just start somewhereanywhere!

A few years later, I attended Agile Games 2011 in Boston. Adam Sroka led a session about using TDD to build a Texas Hold ‘Em game. When we started, I recall several people tried to design the whole “system”, and built a long list of things that had to be done. There was more flailing over where to start.

I sat down with Moss Collum, another developer, and just asked, “Where do you want to start?” He handed me the keyboard and I typed:
   public void eightOfHeartsIsGreaterThanThreeOfSpades() {


Since then I’ve used TDD a couple of times for card games. Today I’d probably start with either the Game or the Hand rather than Card. Again, that isn’t because starting with Card was wrong, but I could see getting further in the same amount of time by using a different starting point. Or maybe not - it probably depends on the individual developers.

The main conclusion, though, is that you don’t need to agonize over what the first test should be. You don’t need to agonize over which concept to introduce first. Just start somewhere and adjust from there. The code will show you which way it wants to go.

27 April 2015

Getting Started with Test-Driven Development - My Left Hand

If you’ve done any amount of programming that wasn’t test-driven, the entire notion of writing a test before writing any code may sound odd. I can tell you from my own experience in late 2000 and early 2001 that it certainly seemed like a strange way to build software. When I first tried writing code in a test-driven manner, it felt more than odd or strange - it felt as if I was using my "wrong" hand to write my signature.

While some people are ambidextrous, most of us aren’t and have a decided preference to one hand or the other. I’m right-handed, and my first attempts at TDD felt like I was trying to write something with my left hand. I noted, though, that it wasn’t the first time I had encountered that feeling.

So, About My Left Hand

I was born and raised in the same town that James Naismith, the inventor of basketball, was raised. I even lived on Naismith Drive for over 15 years! Needless to say, basketball was a big thing in our town. I played during high school and even into my late 30’s in recreational leagues. We had a park with a basketball court right outside our back yard, and a bunch of us played constantly from when the snow melted in the spring until almost when it fell again in late fall.

My Dad also loved basketball and on a few occasions he came over to the park with me to shoot some hoops. One of those times, we played a little one on one. Dad noticed that I dribbled mostly with my right hand and all my shot attempts - even layups - were right handed as well.

For those of you who’ve met me in person, I’m not what you would call the prototypical basketball player. I’m a whopping 5 feet, 6 inches (165cm) tall and was blessed with endurance more than speed. Dad pointed this out and said that I needed to find other advantages when playing, since most (OK, all) of the players defending me would be taller and probably faster. That advantage would be to be able to use my left hand as in addition to my right when dribbling, passing and shooting. Other players wouldn’t be expecting someone right handed to use their left hand as much.

Dad was never one to give a lot of advice, so when he did I usually listened. I believe it was June when he suggested that, and I proceeded to spend the next two months of the summer trying to use my left hand as much as possible. And I sucked at it. I could hardly dribble, passing with my left hand was a joke, and shooting simply wasn’t happening. I was able to start making layups pretty quickly, though, which gave me some hope.

By the end of the summer, not only was I making layups but I was comfortable dribbling with either hand, I could make passes using my left hand that I had never been able to do before, and I could make shots with my left from almost anywhere within 10 feet of the hoop.

Let’s jump ahead now to the basketball season the following winter, when I was the starting point guard. I was much more effective because I was no longer limited to dribbling with my right hand. I could dribble away from defensive pressure and my new capability to pass with my left hand helped get me out of trouble when I couldn’t dribble. It also allowed me to make passes that the players on defence weren’t expecting.

To that point, I clearly remember one playoff game where I drove to the basket with a defender right behind me. When I went up for the shot his hand and arm were over my right shoulder, expecting a right-handed shot. I simply used my left hand instead and sank the layup. It was exactly what my Dad had said would happen the previous summer.

I actually had progressed to the point that I was more comfortable using my left hand on fast break layups than I was my right. That was in the early 80’s and it stayed with me right up until I hung up my Converse’s in the mid–2000’s.


Our brains are incredible - they have a capability called brain plasticity. You will hear about people who’ve suffered a brain injury, a stroke, or have had tumours removed and lost control of some part of their body. Through physical therapy they are able to regain some, if not all of their previous ability because their brain re-learned how to do whatever function had been lost.

Learning to play basketball with my left hand used the same concept, although I hadn’t lost anything. Our brains are capable of rewiring themselves to allow us to do things we hadn’t been able to do before. This isn’t a fast process, though. It takes time and repetition. It took me over two months of practice and repetition to have my brain create new pathways to provide the coordination to use my left hand.

Learning Test-Driven Development is very much the same. It takes time, practice and repetition for your brain to transform it from feeling like trying to write with your opposite hand to being the natural way to do things. From being almost impossible to me preferring to do layups with my left hand.

The question now is, how do you get started?

Don’t Be Embarrassed

The first time you try TDD, it will feel awkward. You will probably be quite self-conscious if others are present because you’ve been used to writing code and shipping systems using a traditional approach. Don’t worry about that - any new technique will feel odd, and this has no bearing on your ability to program. If someone asks why you seem to be going more slowly, tell them you’re using your “wrong hand”!

Use the Buddy System

Probably the most important thing for me when I learned TDD was that I had a “buddy” doing it with me. We shared our discomfort, laughed at each other, and learned together. We also pushed each other. I wasn’t going to give up if he wasn’t!

This concept is actually pretty standard for any behaviour changing activity. Weight loss programs like Weight Watchers use the buddy system. Alcoholics Anonymous has sponsors who work with a person. Those people have “been there” and can relate their experiences.

Do the same with TDD. Find someone who wants to learn as well. Pair with them. Make mistakes together and laugh! Learn together, knowing that you both will get better at it.

Practice Makes Perfect

Over the summer that I learned to use my left hand in basketball, I would be on the court almost every day, sometimes twice a day if I had the time. There were a bunch of us who just showed up each night when the weather cooperated. We played a ton of basketball that summer (and many others as well)! You can do the same while learning TDD.

There are code practice sessions called Katas that are extremely helpful when you’re starting out. You can spend 15–30 minutes working on one of the kata programming exercises such as Prime Factors, Fizz Buzz and a String Parser among others. That practice will take you from that awkward, uncoordinated, “using my wrong hand” feeling to a natural flow.


Test-Driven Development is a development technique that comes with what I call a “learning cliff”… it’s simply too steep to call a curve! However, using these steps can help you scale that cliff relatively easily.

Find someone to scale the TDD cliff with you. Try it out, practice and compare your experiences. Most of all, though, be patient! It will take some time and you likely become frustrated at some point. Remember that the outcome of clean, well-factored, well-designed code that happens to have a comprehensive set of tests describing its behaviour is more than worth the effort.

More on that in later posts!

16 April 2015

It's Just a Feature for Feature Port

Ah, the 80's!
A long time ago, in a galaxy far, far away known as my teenage years, I used to watch the popular CBS show Magnum, PI. The show's protagonist, Thomas Magnum (portrayed by Tom Selleck), had a running self-narration throughout the show which helped fill out the plot and characters.

One line of narration that Magnum often spoke was, "I know what you're thinking...". He did this when it was clear to the audience that he was about to do something that wouldn't work out all that well, and used it to explain why he was doing it anyway. Usually there would be unforeseen complications that led Magnum into danger and from which he would have to extract himself and others in dramatic fashion.

Gotta love Hollywood!

Regardless of how "80's" the show may seem today, that line - "I know what you're thinking" - has stuck with me. I've even used it myself several times during my software career, each time when someone is porting some functionality to a new language, framework or platform.
It's just a simple feature for feature port. We don't need to figure out the requirements. We don't need the business people until the end. We aren't going to add anything new or change the functionality at all!

6 April 2015

Experiments, Not Failures!

In the Agile world we the often hear statements like, "Fail fast, fail often", and "Failure is how you learn". Equally often we hear about organizations whose culture disapproves of failure. We say that such organizations will be a difficult fit for any Agile process and there will be much pain and suffering during the transition.

But what do we actually mean by the term failure?

When performing technical coaching, I've adopted Mike Hill's terminology of microtest to replace unit test. Why? Because unit test has accumulated all sorts of "baggage" over the many years it has been used. At one client, a unit test was something that could take developers two weeks to write. At another client, a unit test was performed manually by QA people. This overloading of the term makes it quite difficult to achieve a shared understanding of testing, for example.

Does that same problem exist with the word failure?

26 March 2015

Changing the Tires

You're driving down the highway trying to reach a distant destination. You've had delays such as traffic along the way, and you know that you're going to have to "push it" in order to have any hope at all of arriving on time. You start to feel something strange in the steering wheel. The car seems to be pulling to one side and the steering is rather "mushy". It dawns on you that you're losing air in one of the tires.

Ugh. You've already been delayed, and you really need to get to the destination on time.  Perhaps there's a store that will be closed. Perhaps an important meeting that requires you to be there. Regardless, a tire that's becoming flat will certainly delay you more than you can afford.

So, what do you do?

16 March 2015

Mary Had a Little Lamb - The Power of Shared Understanding

I spend quite a bit of my coaching time helping teams improve how they determine what needs to be built in order to satisfy a business need. I warn them right from the start that they're going to hear me repeat the same term many, many times before they get rid of me. That term is "Shared Understanding".

There's a thinking tool that I use to help people understand what shared understanding means. I go to a whiteboard or flipchart and write the following:
Mary had a little lamb.
I then ask the group what that sentence means.

5 March 2015

The 100% Utilization Myth

Many organizations in which I've coached are concerned when the people on their teams aren't being "utilized" at 100% of their capacity. If someone is at work for 8 hours per day, minus an hour for lunch and breaks, that's 7 hours of potential capacity. Some organizations are progressive enough to see that the organization's overhead of administrative activities lowers that value to 6 hours per day. By extension, a team's capacity is simply a multiple of the number of team members and the number of hours available to be utilized, i.e. a team of 5 has 30 person-hours per day.

So, anything less than 30 person-hours per day spent on tasks means that a team isn't being utilized 100%. Which is bad, apparently.

25 February 2015

People and Resources... again.

Despite the protestations of many people, the term resource continues to be widely used as a synonym for person. I've written about it before, but I'd like to explain again why I feel so strongly about the issue.

This is lumber, specifically spruce. Suppose I took one of the 2x4s from the pile, put it back and took another. I could be reasonably certain that both 2x4s had close to the same physical properties with respect to strength, dryness and size. There may be slight variations if the 2x4s came from different spruce trees, but the properties would be close enough to consider those pieces of wood interchangeable.

24 February 2015

You Won't Believe this Absurdly Wrong Design Decision!

I'm often asked if the principle of emergent design used by many agile teams really makes sense. Usually the question comes from someone who is heavily involved in the design process, such as an architect or senior developer. That person may have spent years designing software, and is somewhat uncomfortable with the idea that the hard work done up front can be adequately replaced by allowing design to emerge through an iterative process.

So, I wanted to talk a bit about how I approach that question and emergent design in general.