On T(est)DD, M(onitering)DD, O(bservability)DD and H(ypothesis)DD

This article originally appeared on medium at https://medium.com/@defmyfunc/on-t-est-dd-m-onitering-dd-o-bservability-dd-and-h-ypothesis-dd-5eb6beb7b64b

Technology is now once again helping us automate what the best businesses and teams have been doing manually for a while (perhaps without knowing it!). With that ability to make systems that are ‘Observable’ we are now once again able to move TDD one step closer to our users. We should leap at the chance :)

As an ardent TDD-er I find the current conversation around Observability and our ability to automate and drive value from this especially intriguing. Whilst there are probably lots of people talking about it heres one twitter link that explains things well:

https://twitter.com/mipsytipsy/status/1102430797535952896

Whilst I now work at ThoughtWorks, I never did when Barry O’Reilly worked here, but he wrote an excellent post about using hypothesis to drive value in your business and teams here:

How to Implement Hypothesis-Driven Development

and I still use this framework when I am working with our clients.

So whats changed?

As ever in tech, nothing and everything.

What hasn’t changed?

TDD fundamentally hasn’t changed. For me, TDD is purely an expression of value. TDD allows me to understand the value I want to give and it operates at the level you, your team and your business need it to operate at. High, Medium or Low. The ‘Test Pyramid’ is the basic expression of that.

When I was inexperienced in TDD, often this meant that I really focused on low down tests, but this was because I struggled to think outside the box I was given. I needed that focus to help me understand. As I grew in experience, I found value the closer I got to the user.

For instance, I started practicing ‘Outside-In’ testing:

Finishing “My Lists”: Outside-In TDD

because this allowed me to think about failure first. I have been paraphrasing this to my teams as ‘F(ailure)DD’ over the past few years.

As our ability to manage complexity through tooling has grow, so has our ability to understand the value at the edge of our system and ‘FDD’ alongside ‘M(onitoring)DD’ over the last few years has I think, provided the right balance of design and value for relatively mature teams and was pretty much ‘as good as it got’ in my experience. I wrote about it here:

Releasing value in software development

This was only possible due to the progress of technology.

In reality, what was happening was that technology was starting to catch up to businesses.

Businesses have always been way ahead of tech in most sectors. This was most evident during the last 30 years when tech was so far behind the businesses ability to change they were often seperated out into their own departments and treated as a cost centre. The world did, and still does, run on excel, not because its the best, but because it can change.

As technology consultants some of our clients are dealing with this legacy, in business and sectors that didn’t know they were technology companies until a technology company came and ate their lunch.

The drive towards more ‘Lean’ business models (I don’t profess to know a lot about this so please forgive the quotes) has meant that the ‘Outside’ of our ‘Outside-In’ testing moves closer and closer to the edge of our system (system in ‘systems thinking’ definition of that word)

What has changed?

Technology. We are now able to create highly observable systems that are within the financial grasp of most business and teams if we wish. This is something that hasn’t really been possible before.

Technology is now once again helping us automate what the best business and teams have been doing manually. With that ability to make systems that are ‘Observable’ we are now once again able to move TDD one step closer to our users. We should leap at the chance :)

The views in this article are my own and are not necessarily endorsed by my employer.