Archive for the ‘Uncategorized’ Category

Legacy Code Change – a Boy Scout Adds Tests

Tuesday, August 3rd, 2010

Here is a legacy code change policy for a team adopting TDD that has a legacy code base:

  • Test-drive new code
  • Add tests to legacy code before modification
  • Test-drive changes to legacy code

Refactoring without tests is dangerous; with all the details we must keep straight, a mistake is easy to make. How many code reviews have you been in where the recommended design changes are not made because “we already tested it”? You avoid the change because it’s dangerous to change code without tests. So, the Boy Scout adds tests too. For more on Boy Scouts, see previous post.

(more…)

Posted in Uncategorized | No Comments »

Deep Agile Panel Questions – Change

Wednesday, May 6th, 2009

Prior to the Deep Agile conference, I received a number of questions about getting people to change, to try new things. Change is hard. People need to be motivated to change. “If it ain’t broke, don’t fix it” they say. But there is always some things that are broken.

First there needs to be awareness/acceptance that there are problems to solve. Do a retrospective of the last release. Find the problems that people are passionate about. Try not have blame session. Build a logic chain from the problem to some solution you think will help. Get people to sign up to try the new approach for a month or two, not the rest of their lives. Iterations give a great opportunity for this kind of experimentation.

You have to try things, rather than just talk about them. I am not sure where this quote is from, but it is profound:

“It’s easier to act your way into thinking differently than to think your way into acting differently”

Read on for some specific questions, and my answers.
(more…)

Tags:
Posted in Agile Development, Agile Embedded, Embedded TDD, Uncategorized | 1 Comment »

Deep Agile Embedded Panel Questions – Hardware

Friday, May 1st, 2009

Last weekend was the Deep Agile Embedded Conference that I participated in. In this article I’ll answer some of the panel questions related to concurrent hardware development. There seems to be a theme here, because the hardware is involved, an embedded development team really can’t be agile. That’s not my point of view, or my experience. I am not a hardware engineer, but I have worked near them. Let’s see some of the questions and answers.
(more…)

Posted in Uncategorized | 5 Comments »

Don’t Let Embedded Tool Chain Slow You Down.

Wednesday, April 1st, 2009

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?”
(more…)

Tags: , , ,
Posted in Agile Development, Embedded TDD, Test Driven Development, Uncategorized | 4 Comments »

Planning Poker Party (The Companion Games)

Friday, February 6th, 2009

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.
(more…)

Tags: , , , ,
Posted in Agile Development, Coaching, Scrum, Uncategorized, estimation | 13 Comments »

Agile? How do I learn more?

Friday, January 23rd, 2009

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.
(more…)

Posted in Uncategorized | No Comments »

Tests vs. Short Term Cache Between Your Ears

Monday, May 5th, 2008

You have someone else’s code. You have to use it. To use it you have to learn it. If the code had automated unit tests you could read the unit tests to see how the code behaves. But, it probably does not have unit tests. So, you read the documentation. The documentation usually leaves some room for interpretation in the best case. It lies and misleads in the worst case. What do you do? You read the code.
(more…)

Tags: , ,
Posted in Test Driven Development, Uncategorized | No Comments »