Tips and Advice: Test Driven Development

Yesterday, Bob Payne published one of our informal Tips and Advice discussions on the Agile Toolkit. Check out our Test Driven Development podcast and let me know what you think.

Who is…

Yesterday, Yves Hanoulle published his interview of me as part of his Who Is series.  It was a good opportunity for a little introspection about myself and my career. (Continued)

Sad Statements

I hope this will be done by then.

These are sad and scary words to me.  When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations.  Further, it’s likely that there is no good indicator of what can be delivered when.  With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.

We’ve done our part.

This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.

You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.

The Code of Christmas Past

When we write code, we’re often thinking about the short term. We need this code to function correctly so we can deliver within our immediate deadlines. I’ve found it important to also think of the long term. Sooner or later, we might encounter our own code, again.

I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner. (Continued)