During my TDD session at the Embedded Systems Conference yesterday, I did a demo. Before the demo, I make the case for TDD as a way to prevent bugs (see Physics of TDD). For the live demo I usually code on my mac and run the tests there as well. The question always comes up: “You are running tests on your PC, can you run them on the target?” or maybe “Sure you can TDD on a PC, but what about the real hardware?” Continue reading →
High-Low Story Showdown, Deal and Slide, Developer Guts, and Customer Guts
It’s sprint zero and you have a stack of stories needing a first estimate? You need an initial release plan. What should you do? It’s kind of hard to start on day one with Planning Poker. There is a missing baseline to estimate against. Continue reading →
LinkedIn is fun. Every now and then a person from the past pops in. A colleague from my early days at Teradyne had just heard about agile and she asked me what it was and how to learn more. Here’s what I told her. Continue reading →
Adding tests to legacy C or C++ code can be a challenge. Code not designed to be tested won’t naturally be testable. Dependencies will be unmanaged and invisible. Getting that first test written will hurt, a lot. Don’t despair! The first test is the hardest, but subsequent tests are much easier.
Knowing what to do and what to expect, when you start adding tests to your legacy code, can ease the journey. This article will give you an idea of what to expect when getting that first bit of C or C++ into the test harness. Continue reading →
At Agile 2008 James Surowiecki, the author of Wisdom of Crowds, gave the opening keynote address. If you have an opportunity to hear him speak, take it. He did a great job. No power point slides with a compelling style and message. Continue reading →
Should a team use story points or ideal days for estimation. Story points have clear advantages.
An ideal day is this thing that never happens. You get to work, everyone else took the day off, except when you need to ask them a question, then the needed person is immediately available and willing to help you. On this ideal day your goals are clear and so is your head. So really, there is no such thing as an ideal day except in our imagination. Continue reading →
Test Driven Development is a challenging practice. Why should you bother to learn it? You should learn it because it is a productive and predictable way to develop software.
Let’s compare TDD to the most popular way of programming, something I call Debug Later Programming. In DLP, code is considered “done” after it is designed and written. After the code is “done” it is debugged. Hmmm. Interesting definition of done isn’t it? The definition fails to include about half the effort.