A day of intensive TDD training

Last Saturday (25/7/2015) found me in South Wimbledon attending a 1 day intensive TDD training course being run by Jason Gorman from codemanship.

Although this course is usually run over 2 days codemanship occasionally run the course as a reduced price 1 day intensive format.

I had decided to attend because although I have been trying to do TDD for the past few years I have never had any formal training so wanted to check what I was doing was correct and see what else I could learn about TDD.

Introduction

Once everybody was set up Jason told us what we could expect from the day starting from the most basic TDD techniques progressing through you use TDD to drive the design to using mocks/stubs and finally applying techniques to work out behaviour required from user stories.

Jason pointed out that when you first start doing TDD you need to be mindful of what you are doing to ensure you are following the practices we would be doing that day as it was easy to slip into bad habits, this will mean you will be slower until you become comfortable with the various practices but you would become faster the more you did them.

TDD Back to the beginning

After the introduction Jason took us right back to basics explaining the red-green-refactor cycle and stressing that the refactor part is just as important as the test to ensure you end up with good code.

Jason then had us pair up to write tests/code around transferring money between two bank accounts, in fact all activities during the day were done as a pair which was great as I also got to practice pairing with different people. 

Jason didn’t give us any specific guidance about how we should do this, other than write a failing test, make it pass, refactor – not forgetting to refactor tests as well.

After you had created an object oriented way to handle the transfer Jason got us to go back to just doing it with variables and then refactor that to find and eliminate the duplication, teasing out methods where necessary and giving you insight into

More TDD Basics

After the first exercise Jason talked to us some more about the techniques you use in TDD to help drive the design of the code such as tests only having one reason to fail, always write the assertion first, triangulation, etc.

One thing he stressed was that the idea isn’t to do no design before you code but only do enough design to inform where you start your tests (something we came back to later).

Triangulation was something that really helps with this as Jason explained you want to be driving from a specific solution towards a more general solution, writing meaningful tests which are self explanatory using data that helps tells a story e.g. boundary values.

Another thing that was highlighted out was writing the assertion before you write the code isn’t just to ensure you have a failing test but to make you think about what it is the code needs to do to satisfy that assertion,  and the assertion should be related to helping satisfy the requirement(s).

Armed with this new knowledge we tackled our second example of creating a Fibonacci generator.

Yet more TDD Basics

After the second exercise Jason talked to us about refining what we were doing, isolating tests, never refactor with a red test, test organisation, etc.

Another key point here was to pay attention to the requirements so that you didn’t needlessly create tests that you had to throw away later, this tied back to writing the assertion first to make sure you are writing a test that helps satisfy the requirements.

Jason stressed again the need to importance of maintaining the tests, this means refactoring the tests where necessary to try to ensure they are clear, easy to understand and testing what is necessary (circling round to not writing needless tests)

We then tackled are 3rd and final exercise of the morning having to create a FizzBuzz program with with some additional requirements.  If we completed the initial work Jason challenged us to rewrite the generator so that it didn’t use any conditional statements when generating the sequence i.e. if, switch or tertiary operations.

Test Doubles

The afternoon started with Jason touching on the London & Chicago schools of TDD and how the London school favoured the use of the various types of test doubles to allow testing of interaction between classes.

After discussing the various types of double we jumped into our first example of the afternoon creating a system (in the loosest terms possible) that could tell you if you were able to book a holiday for a specific week of a specific year.

Pulling it together

When we stopped the 4th exercise Jason started talking to us about how we pull all of this together to help design a system.

Users & goals

He talked about determining requirements and how a common way to capture this information was via user stories.  What was stressed though is the user story should be seen only as the starting point for a discussion, hopefully with the user, to get more details around/about the functionality needed.

We utilized the Given…When…Then format to get this additional information with each of the then clauses becoming the requirements to be satisfied. Although this helped us gain further understanding about what was required Jason pointed out that they weren’t executable specifications, to understand specifics we needed concrete examples for each then to allow us to create tests that can satisfy them.

Class Responsibility Collaboration Cards

With this additional info could examine the stories to determine the roles, responsibilities & collaborations that we believe we need and to help us visualize the objects we used Class-Responsibility-Collaboration (CRC) cards where we have 1 card per role (object) listing its responsibilities (methods) and other objects it communicates with (collaborations).

This helps to enable a “tell don’t ask” design where you communicate by message passing  which also identifies boundaries where you can mock the interactions when you come to writing the tests.

Testing the design

We then did an exercise where in a pair we took a user story, created expanded details and added specifics then Jason took our finished work and handed it to another pair to create the CRC’s for it.

Once everybody had completed the CRC’s Jason took one or two and showed us how we could test the design by running through the Given...when…then and seeing if the objects and interactions would successfully satisfy the criteria.

Finishing up

Jason re-iterated what he had said at the beginning that we needed to ensure we practiced the techniques we had learnt today as if we didn’t practice it was easy to slip into bad habits and asked us all to think about what we could do to practice.

We all then went to the pub to have a drink and discuss the day a bit further.

My thoughts on the day

Firstly I can see why this is billed as an intensive course, we really didn’t stop during the day. Ideally I would have liked a little extra time doing the exercises but in general I liked the pace, it kept you focused on what you needed to do without overloading you.

I really enjoyed the course, it reinforced my existing knowledge, highlighted areas where I have picked up bad habits and I came away having learnt more around triangulation and using CRC cards to test specifications.

Whether you are a complete beginner or have been doing TDD for a while I’d recommend this course, I’m sure you would get a lot out of it.

Agile…..its all about the code

Over the last few posts I’ve talked about principles, I’ve talked about culture and mentioned methodologies.

Although I’ve touched upon development/engineering practices in most of these posts you could be forgiven in thinking that these practices are unimportant or just another thing you should do.

This couldn’t be further from the truth.

The key to achieving success with agile in software development is by implementing the various development/engineering practices.

Without these practices “agile” just becomes a different way to organise the work, it doesn’t improve the quality of the code and it doesn’t speed up development.

On the flip side just adopting the development/engineering practices won’t help protect the team from being bombarded with requests for work, having to chop and change between projects or working on “the wrong thing”, the other agile practices exist specifically to help the team with this allowing them to focus on getting software into the hands of the users/customers, which after all is the ultimate goal.

Agile Culture - is it a thing? is it important?

In the last few posts I've covered a variety of aspects of agile, how the artifacts and practices associated with agile don't make you agile, the underlying concepts in a good agile team, how agile methodologies are just tools and the benefits that you will hopefully see with a fully agile team/business.

A couple of times I've mentioned agile culture but not tried to actually define it in any meaningful way or described what it is and why it is important, so this post I'm tackling just that.

What is an organisations culture?

Before trying to define what an agile culture is its worthwhile defining what culture means in this context.

I looked around the internet and found a few different definitions about what culture is (such as here and here) and I believe you can generalise the various definitions and say that:

Culture is the combination of the values, beliefs, practices, etc that people in a company adhere to.

Some of these may be explicit e.g. a mission statement and others may be implied e.g. social norms in the company.

Whilst a company may have the same values and beliefs as another company, the implementation of those values, beliefs & social norms may well differ resulting in a different culture even though at their core they are based on the same things.

Agile Culture

Having defined what a culture is, and understanding that every companies culture is going to be different, what values, beliefs & practices could we reasonably expect to see within an agile culture?

Embracing agile principles and practices

Unsurprisingly an agile culture is one that embraces agile principles but not just within development teams but throughout all aspects of the business that are involved with project/products.

Not all agile practices are appropriate for people outside of the development team e.g. TDD, but practices such as sustainable pace, value stream mapping, limited work in progress, transparency, etc are suitable across the business so everybody can benefit from using them.

Focus on delivery

One of the tenets of agile is "stop starting and start finishing" it is about delivering and people in an agile culture do just that across the business in relation to whatever work they perform.

Value of a piece of work is understood

Agile talks a lot about value (I wrote a post about this a while back) and wanting to focus on delivering value for the business. In an agile culture this idea is understood across the organization which can make decisions about prioritisation and delivery easier since when people have to make a decision they do so with the common understanding of the value that they believe a piece of work will provide for the business.

Actively seeks feedback

How do people know if what they are delivering is the right thing? they seek feedback.

When it comes to feedback a development team is spoilt by all the different forms of feedback they have available to them - unit tests, continuous integration, product owner/champion, users, etc. For other parts of the business the form and type of feedback will depend on what is being delivered, and who it is delivered to, but that doesn't stop them seeking feedback be it from a person, team, department or company.

Learning

Many organisations want to promote a culture of learning due to the benefits that it brings, an agile culture has an advantage with the feedback mechanisms providing information about what is delivered and what may need improving.

The other advantage is that agile methodologies have built in practices such as "Inspect & Adapt" from Scrum or "Continuous Improvement" in Kanban which actively encourage teams to look at what they are doing to enable them to improve how they work.

Good companies don't just stop at looking to improve processes but also encourage individuals to learn, understanding that if people learn they bring that knowledge into the organization and the business ultimately benefits from that.

Do companies with an agile culture actually exist?

So is this an actual thing? When people hear this description they frequently comment that this "sounds great in theory, doesn't work in practice" or they say it seems like an agile nirvana or fantasy, and I understand that for a lot of people it seems that this way of working is a million miles away from how their own businesses work day-to-day.

Probably the most well known company that you could point to as appearing to works this way is Spotify (checkout these blog posts for more detail Part 1 and Part 2).

I have myself worked for companies that came very close to what I have described, they may not have implemented everything I've outlined but they focused on ensuring the team could build & deliver the software without putting any unnecessary roadblocks in the way.

Is this important?

I believe that working this way is very important, it helps companies understand that although the development team are the people producing the software they are only one part of a larger process which involves everybody upstream & downstream of the developers; companies need to understand that this larger process is what generates the companies income and the true cost of any project/product is related to everybody involved in the process, rather than just one part of it.

More explicit knowledge of how the various parts of an organisation interact helps to identify where any bottle necks exist slowing the delivery down, allowing a company to focus on the problem area rather than just presuming they know which part is causing the problem, often incorrectly.

Possibly the biggest advantage is having people in an organisation understand the larger process, it may not change the work that they do day-to-day but it can mean they understand their impact on other peoples work in the company, plus they are able to weigh decisions they need to make based on feedback received, perceived value and what needs to be delivered, rather than simply "doing what they are told to do" people hopefully become engaged, active participants rather than sheeple.