The Automated Unit Testing Journey

The Automated Unit Testing Journey

Test Driven Development or TDD is very common in modern software teams but is not universal. Many career developers are only just stepping, blinking into the light of what it takes to be a successful developer in today’s software projects. There are many stones yet to be turned which surface more developers who are still to go on the TDD journey. This post is about the things you might need to do to walk the path to TDD enlightenment.

If you want a team to do TDD the very last thing you should do is mandate it. It is a bit like telling your child to clean their room. You know by telling them to do something, it will be the very last thing that they will do. No one likes being told they have to do something. At best the team will go through the motions, make token efforts and blame you when every task take twice as long because “we have to do TDD”. At worst you will have downright descent where every discussion becomes an argument about why TDD is a bad idea.

If you want a team to do TDD they have to want to do it. You have to create a movement

Take the first step

You’ll often work with codebases with little or no test coverage. Spend time reviewing the code on your own or with other developers. Look for the core business logic and the parts of the system that are commonly used. Start adding tests around these areas yourself. Depending on your role, the type of project and the organisation you work for you might have to do this in your own time.

Find your first followers

Writing tests yourself will only go so far. If you are not careful your helpfulness will become a hindrance. For example, when someone starts to refactor the code base and finds that lots of your tests no longer compile. If you can’t create a following, you are just this mad guy causing lots of problems. So, be public about what you are doing and why. Pair with other programmers and show them how things work. If you do create a problem, drop everything and sort it out.

Move to the Tipping point

Once you have a few followers publically demonstrating what they are doing more people will join you. Use that time to make the process smooth. Is it easy to run the test suite and does it execute quickly? Fix problems you find so it becomes more difficult for people not to join in.

Cross the tipping point

Soon you’ll have more people involved than are resisting. The momentum your following generates eventually makes it harder for people not to follow. This includes ensuring that test suites run as part of a continuous integration setup and the code is refactored to make it easily testable. The codebase will become simpler and easier to maintain. Over time clear design patterns will emerge… patterns that are easier to test.

The following

Soon the advantages of unit testing will be clear to the team and those interacting with them. The team will be more confident maintaining the code, many existing code issues will have been identified and resolved. Perhaps the tests will have stopped mistakes finding their way into live.

And here is the rub, I haven’t written about TDD yet. Code that is more testable tends to make developers think about how they will test code as and (hopefully) before they write it. Your following will self-organise around the best way to provide automated testing and this may lead to TDD.

I never tell or even ask teams to do TDD. I don’t evangelise that red, green refactor is the only one true way. I have seen enough Test Induced Damage from teams that have done this religiously without really understanding what they were are aiming at. What I ask for is the team to be good engineers and provide some level of test coverage for regression confidence and start a journey towards regular stable and reliable releases. If TDD emerges from this then all well and good but TDD is simply a tool or a technique, it is not the goal.

This post and the idea of building a movement around automated unit testing is inspired by this TED talk. It is one of my favourites.

Armchair Psychology for the Agile Practitioner

Armchair Psychology for the Agile Practitioner

Modern software development is as much about people and relationships as it is about programming languages and tools. A single developer, no matter how good, is never going to be as effective as a highly performing team. Over years working in such environments I have built up a rudimental understanding of the psychology behind teams, good and bad.

Confirmation Bias

People like to work within a framework of beliefs. We use this framework to make decisions about what is right and what is wrong, to predict what will work and what won’t. We favour information that confirms our beliefs and discount information that doesn’t. The difficulty is that everyone will have a different set of beliefs. When we are confronted by opposition the natural instinct is to assume that you are right and the others are wrong. People don’t like to think they are wrong, and so filter out information that does not confirm their pre-existing beliefs. This is confirmation bias.

Confirmation Bias is often behind resistance to change. It can be why organisational transformation is difficult. It is the PRINCE2 advocate that tells you all Agile projects fail because they heard about one Agile project that went wrong and they have too much invested in their certifications. It is the Microsoft .NET developer with 10 years in the stack who refuses to work with Javascript.

It is possible for people to change their beliefs but there needs to be a reason. Usually it is down to self-preservation. If there is an obvious benefit to change, they will change. It is just a case of finding the right motivation.

Sometimes it is possible to integrate both beliefs. The militant .NET developer may consider using Javascript if they moderate their views. Again it requires the right motivation, so if they see a person or organisation they hold in high esteem change, they might change too.

This sums up confirmation bias for me

Bandwagon Effect

The probability of one person adopting a belief is proportional to the number of people who currently hold that belief. Ever feel like you are swimming against the current, when everyone is against you and you’re the only person talking sense. This is the bandwagon effect.

The bandwagon effect is why it is hard to argue your point in a group of three when the two others hold the same opposing views. It is also why you can influence the direction of a team by ensuring that you have a core set of people who share your beliefs.

Information Bias

This is the assumption that the more information you have; the better decisions you will make. This is not always the case because information can be contradictory or bring its own bias to the table. Often people can make acceptable decisions with a lot less information. It is usually better to make a decision using the information you have, rather than deferring it.

People who suffer from information bias can struggle in Agile environments. Generally, user stories are brief and are likely to be missing “all” the information. Analysis paralysis ensues as the team strives to obtain a complete picture. Successful Agile projects tell us that all the information is not required, or at least it is not all required up front. A successful outcome is achieved through feedback and collaboration, experimentation and testing rather than amassing all available information at the start.

Overconfidence

Many of us are so confident in our abilities we will make commitments on behalf of ourselves and our teams without assessing the risks. Often it is the experts that are the over confident people as they are convinced they are right. How many times has an expert in your project under estimated the complexity of a feature, made a commitment and then the whole team finds itself under pressure.

Sunken costs fallacy and the impact on Agile teams

A sunk cost is any past cost that has already been paid and cannot be recovered. In IT this may be the time (and therefore resource costs) of gathering requirements, or doing an architectural study or refining a design. This time and effort is gone and cannot be recovered.

However, many people look at this differently. “It cost 20% of the project budget coming up with the design so we need to implement it otherwise we’d have wasted our money”. Did anyone stop to think if the design was appropriate or whether the requirements had changed or whether the product was even needed anymore.

Upfront planning is a common cause of sunk costs. The longer and costlier the planning phase, the more temptation to see it through. Agile projects go some way to address this by doing regular planning and therefore minimising the perceived costs lost if the direction of the project changes.

In large scale Agile projects, you may have a team of people working a sprint ahead, getting stories ready for the next sprint. This team will be fleshing out the details of stories, decomposing them, working out dependencies and even defining the order in which they need to be delivered. This looks good on paper but in this model without the SCRUM team’s involvement not much of the planning will remain intact when they do get involved. Sunken costs come into play because the “design team” are reluctant to throw away all that effort. The SCRUM team then become disengaged because they are simply implementing someone else’s design. All the Agility you have tried hard to gain is lost.

In IT there is no finished, only what’s next?

In IT there is no finished, only what’s next?

Agile frameworks such as SCRUM major on the Definition of Done, or DoD. In the SCRUM the DoD is used to keep the team focused on all of the activity necessary to take a business requirement or user story from conception through to being used by the end customer. This is shared understanding across the team and the concept is applied at user story, feature and increment level. Whilst the DoD is an absolute, unequivocal shared understanding of completion in an Agile project, when you analyse the back log of work, there is nothing absolute that constrains scope. The backlog is a list of work ordered by priority that is subject to regular change. Priorities change, and work is added and removed. As it should be. Agile projects embrace change so there should be no hard scope cut off point.

Many Enterprises that are moving to Agile are coming from a more structure project delivery background. Projects have a clear start, middle and end. They agree what will be delivered and the associated costs at the start. This fixed scope is built and tested in the middle and then deployed to the customer at the end. Some organisations when applying Agile, simply use the start of the project to create a backlog of the work, with a “minimal” design, deliver the software using iterations and then mop up the remaining scope at the end. The project is aiming to deliver as much of the backlog as possible given the allotted time and resource and thereby delivering for a fixed cost. However, many organisations struggle with the implied variable scope in this equation and label project’s that don’t deliver all of the intended scope as a failure.

Often these types of approached reflects some of old school thinking that still exists in many types of organisations. You find this primarily in stakeholders that are not directly involved in the day to day delivery of projects. They think about the world in terms of

Project A will cost £444, end on X and will deliver the complete product 123

The project has an absolute cost and an end date, and it will deliver an absolute scope. But the world doesn’t work like that. There is no black and white, only grey, scope will change, risks will emerge and the minds of the customer will change. The delivery of a product needs to be adaptable and flexible not static and absolute. In my experience the vision of a complete project is based on architectural pureness or what was agreed upfront not what was actually needed by the business or customer.

The viewpoint of completeness can be scaled up outside of a single project. Often Enterprise Architects will strive for a complete architectural vision across a business, whether that be an Enterprise Service Oriented Architecture or a canonical data model shared by all business applications. Here a number of projects need to deliver their predefined scope over a number of years for the EA vision to be realised. However, this doesn’t account for change. How many projects deliver exactly their pre agreed scope? So hoping 4 or 5 will is clutching at straws. The reality is that the course of the business will change meaning another Enterprise initiative has only been partially completed. Another failure. But does it matter if the business is still making a profit and its customers are happy.

Organisations are starting to realise that there is no end. There is no point where the stars will align where there is a perfect portfolio of products or a neat enterprise architecture and neither does it matter. There is no end, only constant change and they are adapting to be better at dealing with this change.

IT visions are still required, only they are no longer static. They are presented as roadmaps, where elements in the near future are more certain and fleshed out than those in the distance. As you move through time in the roadmap, not only are elements less defined, there are more alternatives and variations. The roadmap is dynamic and adaptable, exactly like the businesses they need to support.

And how should this roadmap be presented? The model I prefer is to create work items describing what needs to be done. The things that need to be done soon have a lot of detail added and those in the future can just be a place holder. They are given a priority based on how close to the present they are needed, e.g. high priority = soon, lower priority = future, and the work items ordered by priority. This list is continuously refined as priorities change and details added…, somewhat like a backlog!

Sustainable Teams

Sustainable Teams

Outside of my day job I’m a keen cyclist. I say “keen” if keen means looking into training programmes to raise my fitness levels and doing a 40 mile round trip commute to work three times a week. Some people, non-cyclists, think that is mad. If you are a cyclist, you’ll understand.

Currently I’m combining a training programme with my commutes which means some days I’ll be doing a training session and on other days, rest days, I’ll just be riding in at a steady pace. Like many cyclists I capture all my statistics, speed, cadence and heart rate, in an application and pour over the details at every opportunity. What I noticed when looking at my commuting stats reinforced the reason that a team that works at hard but sustainable pace is a better place to be than a team that is running at full tilt from one fire to the next. Read on for my justification.

My training sessions consist of a set of intervals where I push my heart rate into a specific zone. Without going into all of the biology and sport science, this heart rate zone has your body working at its maximum sustainable rate. Here the rate at which the body is consuming fuel matches the maximum rate the body can supply it. When I encounter a hill I have 22 gears to choose from to keep myself in the right zone. I can also adjust my pedal cadence or even my position on the bike. I can call on additional effort, but I can only do so for short periods and it causes nasty side effects, such as the build-up of lactic acid.  If I push too hard it will all go wrong and I will crawl to a halt.

This is the same with a team at full tilt, running from one crisis to another. The team can sustain this effort but it comes at a price. There is no room to reflect or innovate. They have a fixed scope and a fixed deadline and there is no contingency for unexpected problems. They effectively have very few gears to use and are forced to go beyond their sustainable capacity. Again there are side effects, such as having to work long hours and weekends. Technical debt may build up and there is a detrimental effect on team morale. If the team is asked to work this hard for too long the team will fall apart. People may leave the team temporarily or permanently. The team is burnt out, which is equivalent to me leaning over my bike by the side of the road, feeling very ill.

On my none training days I ride at a brisk pace but keep my heart rate a bit lower. I can keep this pace up for the whole trip. If I feel like it, I can do quick little sprints to avoid traffic or nip through a green light. I sometimes use these rides to focus on my form, making sure I am spinning full circles with the pedals rather than stomping, or ensuring I am holding a good position on the bike. If the weather is nice it is an enjoyable experience.

But the interesting revelation comes when I compare training and none training rides. My average speed on the training rides, where I am working harder, is lower than the easy rides. There is not much in it but the statistic does stand out. My training app gives each ride a suffer score which is based on which heart rate zones I was in. All of the training rides get a much higher score. They also felt harder. So why are the easier rides quicker?

When I look closely I can see that the training rides consist of lots of peaks and troughs. The peaks are when I am working hard and the troughs highlight recovery periods. The easy rides have a more consistent profile; I am keeping that effort up for the whole ride. It never reaches the peaks of the training ride but I also don’t spend much time at the lower speeds I do on the training rides. This is what is happening to the team that is working flat out. Over time they are peaking and recovering. They peak during key milestones in their project, usually during releases and they are under performing when the pressure is off.

A team working at a sustainable pace is likely to be more productive. By not pushing the team too hard you are effectively giving it more gears to deploy when dealing with upcoming challenges. The team also has opportunities to look at its form which may improve the team’s overall performance over time. It goes against some classic old school but unfortunately very prevalent management thinking of “Apply pressure and get results”. In my experience this is not sustainable and doesn’t create a team that is a nice place to be. Good talent is hard to find so why would you want to alienate your team members and burn them out.

Yet many organisations do exactly that!