Test Driven Development (TDD): A design activity

Test Driven Development (TDD) is often though of as a testing activity but it really isn’t. It’s a design activity that leaves a bunch of automated tests behind in its wake. It may sound as if we’re spending a lot of time on “tests” but we’re really focusing on the behaviour we want and allowing that behaviour to drive the design of our system.

Quality vs Testing: Solving the wrong problem

In the agile space, we talk a lot about testing. How will we test things? What should we test? How can we automate our testing? Yet, testing isn’t actually the point. What’s important instead, is quality. If we had amazing quality then it wouldn’t matter if we’d tested or not.

World Hypnosis Day

Today, January 4, is World Hypnosis Day. If you’re like most people, all you know about hypnosis is what you’ve seen on TV or in movies, and while entertaining, that’s mostly wrong. You may have even seen a live hypnosis show, and while there will certainly be real hypnosis being done, most of what you’re going to notice is showmanship and entertainment.

Attribute substitution

Attribute substitution is a situation where, when we are faced with a computationally difficult decision, we will often substitute a more easily calculated decision in it’s place and answer that instead, without even realizing that we did this.

Using LEGO to teach technical practices

Years ago now, Bryan Beecham came up with the idea of using LEGO to teach the concept of Test Driven Development (TDD). Since this is a topic most often used by developers, previous trainings had focused on demonstrating this technique on actual code. However, Bryan wanted to introduce it to a different audience; he initially wanted to explain TDD to management and then later to other non-developers on the teams. To do this, he needed to be able to illustrate the concepts away from the actual source code. And thus was LEGO-TDD first created.

Slicing stories

In an agile environment, we split our work down into what we call “stories”, that are the smallest unit of value passing through a workstream. Unfortunately, we have a tendency to over-complicate story writing, making it unnecessarily hard. Done well, it can be a simple process of taking small steps, repeatedly.

Premature optimization

We have a tendency to think that making any one part of the workflow more efficient will make the overall workflow also more efficient and that’s just not true. Part of that is that not all parts of the workflow are on the critical path and improving something that isn’t currently a bottleneck won’t help the overall flow. But there’s a second reason that’s less obvious - sometimes optimizing for simple cases in the workflow, can make other parts of the workflow much worse.

What’s wrong with our meetings?

When we look for opportunities for improvement, at some point every team will bring up “too many meetings” as one of their pain points, even though it’s frequently not the number of them that’s the actual problem.