Last week I pointed out that Test-Driven Development, even though it is named as it is, is not a testing activity but rather the creation of an executable specification.  So how does this change how they are written?  That's the subject of this episode.

This week I wrap up my answer to the question of three weeks ago and is so going point out, perhaps, the most important aspect of TDD, and how to make sure it delivers all the value it is capable of.

Part two of my answer to the question posted two weeks ago.  There is one more to come, next week.  It may be the most crucial of these answers.

This is my first answer to the question posed last week.  There will be two more in future weeks.

Teaching Test-Driven Development, either in the unit testing form for developers or the acceptance testing that anyone can learn and do, this questions almost always arises at some point.  It's actually an excellent question and can yield a lot of value in answering it.  This episode will explain why.

How does this principle apply to the notion of an agile process?  I think it fundamentally changes the way we create automation, and the value that automation ultimately provides.  This week I explain why.

This is kind of a fun one.  I start by pointing out that, regardless of appearances, computers are not really doing any of the things we think they are doing.  Examining this fact, and it is a fact, leads to some interesting and I think useful insights.  Next week, I'll drive this idea into practicality.

Products that are difficult to use or illogical in their design can seriously impede their value.  This episode will examine an example of such a problem, from the author's own personal experience with a new car.

Last week I teased the notion that it's possible to bring your legacy code under better control by using a magic button.  While such buttons obviously do not exist, this week I'll outline how to get the value of such a resource anyway, at a manageable cost.

What is the best way to deal with the fact that most organizations have a high degree of vulnerability to the quality (or lack thereof) of the legacy systems they depend upon?  This week I'll discuss a thought experiment that helps us to understand this conundrum, and next week I'll show you what to do about it.