Financial director (or client's financial director)
With unit tests
Client find something is broken
Reports a bug
Front line support analyses it
Second line support tries to make repro case
Triaged to a developer who has to drop what they're doing
Developer has to analyze bug
Look at broken unit test
This code broke something
This code broke something
(Let's pretend these are the only two scenarios)
An hour is not fungible
Some time in the next week
Immediately at 3pm
Immediately at 5:15pm on a Friday
Immediately at 3am on a Sunday morning
Value is benefit minus cost
Benefit: Probability test prevents bug occurring in production * cost of fixing bug in production
Cost: Cost of writing test + cost of maintaining test
The benefits of quality are less visible
but they are there
How quickly can you get working fixes out the door?
Does adding new features cause a lot of breakage? This is where you lose customers.
Do your customers recommend your product to other people. This is where your business grows. If you need to grow, quality is a better place to focus than features.
Quality provides value - pay for it out of the marketing budget.
What needs to be done
Start recording costs
Get 'them' to acknowledge the problem
Get a budget for tests - with KPI of results
Set expectations properly
This is commonly known as project management…we are very bad at this.
How to get to Dublin
Unit tests deliver their value over time
TDD tests deliver their value when the code is written, so the next slide doesn't apply to them.
Time is not fungible
If unit tests aren't going to deliver value before a crunch point, then they aren't worth writing (at least not on a value basis).
Or if the project isn't going to have much more development done.
These are business decisions…tech people can only help the business people make informed decisions, you can't make those decisions for them.
Unit tests scale linearly
Communication and tools don't
Unit tests ∝ lines of code written
Communication between people
Relative cost of automation
n = programmers on a project, c > 1
And if that doesn't work ?
Life is short
Not your problem, so stop giving a shit
Our sponsors are hiring
Making the value case for Unit Tests
Do you work at a company where there are not enough unit tests in place and things are constantly breaking? Or maybe you have a client that always wants new features to be delivered as soon as possible, without enough thought about maintaining code.
How do you persuade people that Unit Tests should be written? And that by writing them you will improve your code quality and make development be easier? And how many unit tests should you be writing anyway?
This talk will help you:
Understand exactly how and when unit tests provide value in the development cycle.
Who you should be making the case for unit tests to, and what terms you should use to persuade them.
Writing unit tests can't always be justified by the value they provide. Sometimes this means you should skip writing tests. Other times you should still write those tests. Learn the difference between these two scenarios!
Understand how to plan to tackle a backlog of untested code without dooming your job.
Goodhart's law: “When a measure becomes a target, it ceases to be a good measure.”
"You don't have to do TDD in order to get it right," - the thing that TDD actually does is stop the programmer or manager from saying "right, the code works now, let's ship it and not worry about writing tests, or worrying about if the design is even going to be easy to test."