Psychology of Tests, Testing and TDD

Dear Junior

There have been lots of talk about the benefits of test driven development, but there is one element that I think is interesting that I not have seen a reference to - the psychological process.

Pretend that we dive into the head of a programmer (e g me) and see what happens during testing. Let us firest have a look at "classical" post-fact tests and then at the TDD way of writing the test before the code.

If I write some functional code and consider myself finished I will without doubt feel immensely proud of myself - in other words my ego is on a high note. Then I sit down to test it, and let's see what can happen: either I find bugs and flaws, or I don't. If I do not find any bugs, I do not get any extra credits in my own books - I have been exactly as good as I thought I was (but I might feel that I have wasted some time). If I do find bugs I get a slap in the face - I have not been as good as I though I was (and have committed hubris, which is a severe sin on the list of things considered as sins in Sweden). So, even if testing will improve the general level of the result, the activity of testing (per se) will never give an upside, can at best have a zero outcome, and at worse a big minus. Depressing.

So, how do I treat activities that give me no upside, but possible downsides? Naturally, I tend to avoid them, and over time minimize them.

So, I tend to shy away from testing and writing tests; even though I am firmly convinced of their necessity. Depressing.

Driving the development through tests breaks that negative feedback loop. If I write the test before the code, naturally it will fail: I have no other expectation, and the red bar is not a failure. Later on, I write some code, which make the test go green, and I have actually finished on a high note. Great!

Well, actually I have not finished as any TDD-savvy would quickly point out. I have not refactored away duplication and other code smells yet. But doing so will satisfy another part of my ego, the code aesthetics lover that resides inside me. So, satisfying that part of my ego will end the job on a yet higher not.

OK, to be brutally honest: are there no part of TDDs "red-green-refactor" that have the same "can only go wrong" drawback as traditional test-last? Well, there actually are: the refactoring. At best it says: you did not mess up, at worse: you think you where so smart but you failed. So, how come I do not tend to neglect refactoring?

Well, I have already given the answer: I love refactoring, if nothing else for the pure love of nicely crafted code. But also, the refactorings are not only the last cleanup of one part of the job. They are most often also the stepping-stone from which I launch into the next part of functionality to write - so I get immediate feedback from the refactoring as well.

I think writing tests in general, and unit tests in particular are really important. Considering how many that agree, and how seldom it is practiced, we must look for explanations: ignorance, arrogance or malice do not suffice. To see how we experience "writing tests" has helped me to shed some light over the mystery.

Whatever, I think one of the drives for me to do TDD is that is make all parts of the development cycle to be fun.

Yours

Dan

Transparancy of Business Value

Dear Junior

The story-format from Behaviour Driven Development is wonderful in many ways. I have not yet found another format that is even as close to the semantic density of

As <role>
I want <feature>
So that <benefit>.

However, I would like to dive into one particular aspect.

If you have three things collected it is often interesting to focus on two of them and pay less attention to the third. During my student years there was a joke that it was easy to be well-dressed, social, and sober - but you had to pick two out of three.

In this case we have the role, feature, and the benefit. Please play the game of focusing out the role or the feature. I want to dive into what happens if you fade out the feature itself and focus on the role and the benefit. Benefits can be measured in millions of ways, but let us make it easy for us and convert it to monetary business value. If you need help in doing that, please contact closest economist, they have a broad selection of models for company value calculations to pick from.

"As <role> (...) so that <business value>": If we look at the last part, it is a value experienced by someone - and that can be converted to money. If we look at the first part, it tells us which group will benefit. Multiply the size of the group with the value per person, and you have the potential strategic business value of the story.

As an example: last fall I discussed this during a mountain walk with Bryan Basham who work for StillSecure on the Cobia system for configuration of network nodes (e g routers). One of their stories read roughly "As a network admin I want to apply a setting to a group of network nodes, so that I do not need to configure each of them manually". So, why should a customer pay for this functionality? Well, manual repetition of the same configuration converts really easy to cost of labour hours. So, the benefit of having each network admin saving a few hours each month transfer through multiplication to a monthly reduction of costs, which through not-to-advanced economical calculations can be transferred to a now-value. Voila!

The benefit of actually putting a figure on the value of the story is that you can get clearer transparency of the business value through the organisation. When the product owner makes priorities she can have a look at the estimated value as well as the estimated cost (number of story points we will spend on implementing the story). Another way to use it could be to clear out communication with external stakeholders. E g, a seller might have gotten his will through by being the loudest shouter. However, when he is forced to set a figure of the value, he can also be held accountable if he gets the feature, but fail to deliver extra sales. It can also be fruitful for the CTO/CIO to sum up the value of all stories delivered by development in their quarterly report to the CEO. In that way it might become clear that IT development is not just "all costs"; it actually delivers business value, or at least potential value for someone else to realise into actual cash.

Unfortunately, many organisations are not brave enough to see this so clear. For some reason they prefer to see development as a cost which is funded through a limited budget, and which often do not deliver what they should.

Yours
Dan