Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world on how to improve your software delivery. My name is Clare Sudbery, my pronouns are she and her and I am a lead engineer at Made Tech.
On Tuesday, the 21st of September, I had a chat with Daniel Terhorst-North. Daniel is an independent consultant who writes, speaks and does software development. We first met when he spoke at Agile Manchester in 2016, and he remains one of my favorite conference speakers. If you can get to hear him speak, I would absolutely recommend it. Anyway, Daniel has really interesting views on testing and what it actually is. So I was delighted for the opportunity to talk to him about just that.
Clare: Hello Daniel!
Daniel: Hello Clare. Lovely to be here.
Clare: It’s great to have you. I’m so pleased to be finally talking to you. Let’s start by introducing you to the world if they don’t already know who you are. What is your current job, in inverted commas, and how did you get to this point?
Daniel: Good heavens. My current job – I still pinch myself most days when I wake up and go, what am I doing today. I am independent. I run my own consultancy. I’ve been independent for about ten years. When I’m being a grown-up, I describe myself as an Optimiser. So, what I’m trying to do is make things work better. Those things can be software, those things can be teams. Those things can be flow, or value through an organisation. They can be assurance and governance. It doesn’t matter what the thing is, I describe myself as enterprise manure. If you put things in me, they will grow.
I’m 30 years into my career. I’ve had two good ideas in my entire career, and one of those is questionable. I’ve had two original thoughts in my 30 years. Everything else has been me riffing on other people’s stuff. This is why I work really well with other people. If you put me in somewhere I’m like, I dunno. But if you say, “Why don’t we do this?”, then I’m like, “Why don’t we do that brilliantly?”. So how do you take the idea and iterate the idea, riff on the idea, and make it into something really special.
Clare: What we are going to talk about is testing. I originally wrote down a question for you, which is why software is testing important. Since I wrote that question down, I went off and read your article, We need to Talk about Testing. I decided that a better question to start with based on your article is, what is testing?
Daniel: This is interesting. That article took me – from the point where I decided what the title was – it took me three years to publish. It took me two years and eight months of procrastination. I feel like I put a lot out there when I wrote it. Just a bit of context for folks who haven’t read this article – I’m assuming not everyone has read my stuff – I wrote an article recently called We need to Talk about Testing. To give you an idea of its arc, the working title was The Great Agile Testing Swindle. What it seemed to me, talking as a programmer who has been around since the very beginnings of agile. The way I describe it is that I wasn’t a contributor to the agile manifesto, I was a very early consumer. Things like BDD and a lot of that work was deliberately and explicitly derivative of that. I describe it as very much a second generation agile method. It’s inspired by and based on.
Clare: Just for those that don’t know, BDD is…?
Daniel: Behaviour Driven Development.
Clare: Okay, yes.
Daniel: This was my reframing of Test Driven Development. I wrote an article, the first thing I ever published I think, in about 2003, which was called Test Driven Development is not about Testing. I was trying to explain that it was a design method that had a bad name. That line of thinking led me to what if I reframed what test driven development is? Which I now call Example Guided Design. So, it’s a design method that uses examples as guides. Example Guided Design is exactly correct. Behaviour Driven was a better intermediary name but still wrong.
Clare: Was that one of your two original ideas?
Daniel: I would say BDD was an original idea, but again, it’s a reframing, right? It’s an original work if you like, but it’s very much derivative. So that is one of what I consider to be my two actual ideas. Nowadays I think of the name as Example Guided Design. That comes from Nat Price and Steve Freeman’s wonderful book, Growing Object Oriented Systems, whose subtitle is Guided by Tests. That word guided, when you are writing software, whether it’s commercial software, internal enterprise software or whatever it is, the thing that drives it is customer need, business need. So, you are using examples or tests or whatever to guide what you’re building, the thing that is driving it is need. If the need wasn’t there, you wouldn’t be building anything, so the word ‘driven’ is wrong.
Clare: Yes. So, this gets us to the definition of ’test’, then. What is a test?
Daniel: Well, this I really noodled on. It was one of those boiling frog things. One of the things I noticed over a long period of time is that the testers I knew were becoming more and more homogenised. They were falling into almost a presupposition that you are an automated tester, and you write automated tests, or you are a manual tester. Which is somehow either less or more, depending on which camp you’re in. But a manual tester who just kind of cranks a handle, a button presser, or a manual tester who is an exploratory tester, and they go and come up with new and ingenious ways to break things.
It just seemed like a really odd dichotomy to me, manual versus automated. Then I had this epiphany in probably 2016. The epiphany was this: All of that language comes from programmers. I’m a programmer, I’m a career programmer. If you ask a programmer about x, they will immediately think, which parts of x can I replace with software and which parts can’t I?
If you ask a programmer generally, what testing is, it’s an activity to find bugs or there’s a bunch of different definitions. There is a class I teach called Testing Faster. One of the things I do early on in the class is I get maybe 20 or 30 people and say, “Tell me, what is the purpose of testing?”. You get, as always, 20 or 30 different answers.
It’s amazing what some people think testing is about.
Often you get the very honest, candid, “To tick a box”, “because we have to have some testing”, “because it’s in our process” or whatever. So, I came up with a working definition of what I thought was the purpose of testing. I looked around and all of the testing training I could find, and even the testing literature was typically about various testing habits, tools and techniques and ways of testing, and no one was talking about why they were doing it. There was no, “We are doing this because…”, “We test because…”, so I came up with a very small phrase that has had a lot of thought gone into it. I started trying this out with testers.
The phrase is this, “The goal of testing is to increase confidence for stakeholders through evidence.” The first part of that is stakeholders. I’m not doing this for me, I’m doing this for other people. I think of testing like writing. You write for an audience. If you don’t identify your audience, stop writing. If you’re giving a talk and you don’t know who is going to be listening, stop writing your talk. Decide who the audience is. Decide when you are writing or doing a talk or something what behaviour change you are looking for. What outcome do you want? What do you want to be different once you’ve done this thing?
A really good working definition of quality is; what is it that those stakeholders care about? Let’s say one of your stakeholders is compliance. Quality for them, is it okay to do this? Is it okay for this transaction to happen? Is it okay for these counterparties to know about each other? Is it okay for that medical information to be available in this system? Whatever those rules are, that is their definition of quality.
When we are thinking about testing, we tend to just think along the one axis of functional correctness. Do the answers come out right? But, if it’s functionally correct and it is breaking the law, you probably shouldn’t ship it, right?
So, stakeholders immediately tell you what they care about, what keeps them up at night. I’m sure there are much more formal definitions of quality, but that is my one. It’s the think that the stakeholder cares about.
We are testing along multiple dimensions. A stakeholder is really a cipher, a proxy for a dimension of quality. Security, infosec. Again, secure isn’t a binary scale, it isn’t more or less secure. With security you are always thinking in terms of threat. So, what is my threat model? What am I defending against? How well does this defend against that threat?
I didn’t know that until I started hanging out with security people. Security people talk about threat models and attack surface areas and all of that, rather than secure being a dial that goes from empty to full. That’s not how security works.
Clare: Yes. And if you are testing, you are making sure that your software, your product, is secure. That it is compliant, that it is predicable, accessible, observable. So, what you’re doing with the testing is you are providing evidence to the stakeholders that care about different aspects, that you are providing that quality in whatever sphere it is. That’s what you mean by testing?
Daniel: This is it. The first part is slightly incorrect in that phrase, by the way. I say, “increasing confidence in stakeholders for evidence”. Increasing confidence is slightly technically wrong. It’s actually reducing uncertainty. But reducing uncertainty is a lot harder to get your head around, so increasing confidence is a close enough fit. Here’s what happens. Without any evidence at all, you have a high degree of uncertainty about whether this thing is compliant or whether this thing is secure by your criteria, or whether it is supportable. My operations and support folks are stakeholders too, so we are looking at operability and supportability and resilience. They are all aspects of quality.
Clare: The reason I first got interested in this subject is because I saw you talking about it and basically saying that the thing that I have always thought of as tests because I am a software developer, is basically unit tests because they are my favourite. They are my favourite things that I call tests. What you were saying is they are not tests. Can you explain that?
Daniel: Let’s take a look at that lovely phrase ‘unit test’. Kent Beck is utterly brilliant at discovering and observing and demonstrating things and really not great at naming them. This has been my general experience. Test driven development is one of the most powerful software design techniques I’ve come across in my entire career. However, when you describe it as driven by tests, it’s no and no. Also, when you describe the things that you are writing as unit tests…
What happened was when programmers back in the early 2000s, late 1990s were calling these things unit tests, testers were pulling their hair out and going, “So that’s a unit test?”. “Yes.” “So, you’ve got white box, black box, grey box criteria, preconditions, postconditions, invariance?”. “No.”. Well, stop calling this thing a unit test then! You don’t know what words you’re using. You’re just using words, aren’t you? Anyway, what is your definition of a unit?
Also, this test isn’t a test, it’s a single sample. When you talk to or when you read back what Kent Beck and the gang have written about this, the description is absolutely on the money. The description is, we write this thing as a guidepost and we write a model client ahead of writing the code, so then we know that we have written the correct code.
That’s great, but you don’t know that you’ve written the correct code. You are more confident that you’ve written the correct code, than not having that code example there. I think of it like mountaineering. You put a piton in, then you’re climbing up and you put another piton in. If you fall, you are only going to fall back to the last piton. Also, if you’re just doing free climbing and you fall, you are going to fall a long way. You’re a lot more nervous, right? So, it allows you to make smaller moves.
[Music sting]
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I will work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open source employee handbook on GitHub, which I love. We have unlimited annual leave. But what I love most about Made Tech is the people. They’ve got such passion for making a difference and they really care for each other. Our Twitter handle is @madetech. That’s M A D E T E C H. We have free books available on our website at madetech.com/resources/books. We are currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester office. If you go to madetech.com/careers, you can find out more about that.
Before we return to the interview, just a quick reminder that before the break we were talking about the title Test Driven Development, and how Daniel has come up with a much more descriptive name for that, which is Example Guided Design.
Clare: With this new definition of testing, and this new awareness that actually, what people are thinking of as tests are really examples that are helping to guide their design, what impact does all of this have on the role of tester? The idea that there is somebody whose job it is to test. Who should those people be, and what is really their role, or really should be their role?
Daniel: That’s a great question. I’m going to do the political thing and answer a slightly different one.
Clare: Okay.
Daniel: I need to back up a little bit from there to answer that question. Given that those code examples are just code examples, what does that mean for software development and therefore what should we as teams be doing in order to also be doing testing? Because we thought we were doing testing and we weren’t. Then, given that, how do our testers help?
Clare: Okay, that’s fine, I’ll go for that. I’m interested in hearing the answer to that question.
Daniel: So, what it means is that we have been labouring under a completely false sense of confidence. As a programmer, I’ve got all of the cognitive biases. I’ve got the fundamental attribution error: if it’s a bug it’s probably yours. If it’s a bug and it’s yours, you messed up. If it’s a bug and it’s mine, I was unlucky. I write code and I think that I’m writing code that works. I know that it works because I typed it. If I wanted different code, I would have typed a different thing. This is the thing that I think I need to write.
So, if you were to ask anybody in the world how confident they are about the thing I’ve written, I suspect that I would be the absolute worst person. I would be right on the yes end of the confidence scale. So, I am the last person to ask whether it works. Also, as a developer, I am almost always thinking about functional correctness. I’m always thinking, here’s the feature, here is the requirement, does my code do what it is supposed to do?
I’m not thinking about performance, generally. I’m not thinking about availability. I’m not thinking about resilience or observability. I’m certainly not thinking about compliance, I’m not thinking about legal implications. I’m not thinking about downstream load on other systems. There’s a whole load of things that I am not thinking about because I’m under time pressure, I’m trying to get this thing shipped. It’s busy and it’s nearly lunchtime so I just want to get the work done.
There is this wonderful, very famous response on stack overflow by Kent Beck. The question was, “How deep are your unit tests?”. Someone was asking should you test getters and setters on Java, POJOs and whatever else? Kent Beck replied and he said, “I write as few tests as I can get away with because I don’t get paid to write tests, I get paid to write software that works.”
Everyone went, you can’t say that, you’re Kent Beck! You invented TDD. But it’s brilliant because he’s right. So that says that there is now this yawning gap of; we’ve got something we want to ship as a product – I think of it in terms of change, anything I ship is a change. I may have some stuff that’s already out there, I’m shipping a delta to that. I may have nothing out there, so the delta is the whole product. Basically, what I’m working on is change. I need to think about the impact of that change. Is this change good for the product?
Testing, then, goes back to increasing confidence to stakeholders through evidence. I think I’m done. Let me pause, who are the stakeholders who need to know about this, who may have an interest in this? What evidence would they find useful? What evidence would reduce their uncertainty, increase their confidence that this change is a good change, that is unlikely to introduce any regressions and all that?
That mode of thinking, to me, that is test thinking. Back in the dark ages, we called it impact analysis. I’m going to make this change, what possible impact can this have? Again, one of these unintended consequences of TDD, very early on we had this mantra of run all the tests all the time. Your tests should be small enough and fast enough that you can run all of the tests all of the time. Which is a great aspiration. What it also means is that you stop thinking critically about which tests should I be running because they are significant, and which tests get dragged along for the ride because they are all cheap?
So, we stopped thinking about the impact of change. That impact analysis is absolutely critical test thinking. Now, I can answer your question. I say this to testers as well. I say, the least valuable thing you can be doing for me, is testing. Because even if you are brilliant at it, that makes you a 1x tester. The most valuable thing you can be doing for me is getting everyone else in the team thinking like you think. Because now you are 10x, right?
Clare: One of the things that I really like that you said in the article, is that you talked about the scientific method – that it’s about trying to prove that things are wrong rather than proving that they are right. You expressed it better than that.
Daniel: Yes. This is the whole essence of science. Science is asymmetric. You can disprove something; you can falsify something. You can’t prove something. Newtonian physics was correct for three or four centuries. And it’s still a really good approximation. Unless you are going very, very fast or you are very, very big or you are very, very small, then Newton’s physics works.
Then Einstein came along and said not quite. I can give you some examples where Newton’s physics breaks down and my thing doesn’t. Everyone went, oooh! That was 1905, that was specific relativity. Then in 1915 general relativity. Everyone went oooh! Again, because now we’ve got gravity in there as well.
Einstein turned physics on its head, and then quantum physics came along and said, you know when things are really, really small, they don’t act like you think? Even Einstein said, that’s nonsense. My stuff is pretty wacky, but that’s just nonsense, right? He never really bought the whole quantum thing.
Clare: So, what we are trying to do is falsify the hypothesis. In terms of testing, we are trying to prove that things don’t work.
Daniel: Yes. The way I describe it is a good tester comes up with increasingly ingenious ways of failing to disprove the hypothesis.
Clare: Okay.
Daniel: The more ingeniously you fail to disprove it, the more confident I am in that thing.
Clare: Fantastic, brilliant, I love it. I think we have covered what I wanted to cover, which is wonderful, because we are now out of time for talking about that. I’m just going to go to the questions that I ask everybody. There is one that I normally start with, but I forgot, so I am going to do it now. Who in this industry are you inspired by?
Daniel: I have been in this industry quite a long time, so I have been inspired by a lot of people during that time. I’m going to stretch ‘in this industry’, because I think there are a lot of people outside of this industry that I find enormously inspiring. Recently – I’ll go backwards, chronologically – Amy Edmondson, Professor Amy Edmondson absolutely blows my mind. Psychological safety is one of these things where because both of those words are familiar words, you think you know what it means. You don’t. Until you read Fearless Organisations, until you read Amy Edmondson’s actual work. I found myself reading that book – I’ve listened to some psychological safety talks but no, it’s not the thing I think it is. It’s the thing that she thinks it is.
The things that she thinks it is were so subtle. She came up with this thing 17 years before Google noticed. It was only Google’s project Aristotle that made it famous. That latterly made her famous. She’s an academic, she’s not in it to be famous, she is in it to move the field forward. Generally, I think that is probably true of the people who inspire me.
Nicole Forsgren, another one, Doctor Nicole, right?
Clare: Yeah, she’s great.
Daniel: Massive brain, totally grounded human being. She brought this academic rigour into our scrappy little world of software. I have enormous regard for people who do that because I don’t. I am Mister Anecdote. I have lots and lots of examples of things and sometimes people find those things useful. I’m never going to claim to have solved stuff, whereas someone like Nicole or Amy have the tenacity to say, I’m going to go and do the legwork, I am going to demonstrate that this thing is a thing.
And before them, Virginia Satir. She was the first family therapist. Before her, we had child psychologists. You would take a broken child to the child psychologist, and they would fix them, and send them home. Virginia Satir said no, I need to work with the family. The parents said, don’t be silly, send him home when he is fixed.
But she said, you don’t understand. The child’s behaviour is a presenting symptom of the system of the family. It’s like trying to fix an exhaust pipe. If there is smoke coming out, you need to look at the car. So, she would work with families as a system. She was one of the great systems thinkers. She didn’t call herself a systems thinker, she called herself a family therapist.
People like that, with the tenacity, rigour, and discipline to codify what they do, oh my goodness. In a much less disciplined but still enormously structured way, Andy Hunt and Dave Thomas, The Pragmatic Programmer, is one of those books I go back to every couple of years because there is just so much good advice. Again, distilled wisdom, and it’s timeless. I get inspired a lot. There are certain things that have genuinely changed how I see myself and how I see the world. One other good example would be The Goal, Eliyahu M. Goldratt. It completely changed how I see business. That’s a big thing to suddenly have twist in your brain. I thought I’d got this, no, completely wrong! That’s awkward, oh well, at least I know now, I know better.
Clare: Wonderful, thank you. The next question, and I realise I don’t always explain to people why I’m asking this, it’s a little game. I’m going to ask you to tell me one thing about you that is true, and one thing that is untrue. Then we won’t tell the audience which is the true one and which is the untrue one and then they have to guess. They will only get the answer if they subscribe to the newsletter, because we are mean like that.
Daniel: I was just thinking about this. This may be in the form of a confession. I will tell you two things about me, one of them is true and one of them is untrue and I’m not going to tell you which is which.
The first thing is this; I am a member of the magic circle.
Clare: Wow, I want that one to be the true one. What’s the next one?
Daniel: The second thing I’m going to tell you is this; I have told people that I am a member of the magic circle.
Clare: Woah! Hang on a minute, that is messing with my brain. So, it could be that you are but that you haven’t told anybody, or it could be that you have told people that you are, but actually you are not. Okay, right. Wait a minute – well, you’ve already told me that you are, so…
Daniel: No, I told you that I told people.
Clare: (Laughing) Okay.
Daniel: Before that I did tell you, I love a paradox! Let me reframe my initial answer. The first thing I am going to tell you is that I may be a member of the magic circle.
Clare: I love the whole magic circle thing. My second novel was about a magician. While I was researching it, I got in touch with Paul Zenon, who is a magician based in Blackpool. He invited me over to Blackpool and took me to see lots of secret things, that only people in the magic circle know about. It was fantastic. Lots of fun.
Daniel: Nice!
Clare: I just love the idea of the magic circle.
Daniel: I like the fact that they opened it up as well. It’s not a boys’ club. It used to be a boys’ club, but now it is just a magicians’ club. There is an inner circle, and you cannot apply to join the inner circle, you have to be elected.
By the way, have you spoken to Liz Keogh about fantasy writing?
Clare: I haven’t actually, no. I didn’t know.
Daniel: She wrote a book. One of the characters in her book was all the pigeons in London.
Clare: I love it already. That’s fantastic.
Daniel: You should talk to Liz.
Clare: I was listening to her the other day because I was listening to Randy Silver’s podcast. I listened to her episode, which was about estimation, which I highly recommend.
Last two things. What is the best thing that has happened to you in the last month or so? It can be either work-related or non-work-related.
Daniel: It’s not a specific thing, it’s been a series of things but it’s the same thing a number of times. That is that one of the unintended benefits of working remotely and being at home is I have a three and a half year old son, who is utterly awesome. Sometimes, he is at home, and he just wants to go play. I can just pop out and spend ten minutes running around like a mad thing on the trampoline. We’re squealing and jumping and making loads of noise and all that. Then he’s had his dose of daddy now and he’s back to his toys. It’s just wonderful being able to be available and be present for my little boy. I’m aware that it is such a luxury, such a privilege. If I were working in an office and commuting and blah, these are all moments I wouldn’t have.
Clare: Yes, I love that.
Daniel: I can’t think of a specific one, but that moment where there is that squeal, and you are the cause of that squeal, is just wonderful.
Clare: I know, it’s amazing. My youngest is 13 now, so I don’t get to hang out with small children as much. I watched a film last night, St Francis, which is about a nanny working with a 5 or 6 year old. It gave me that warm glow. That wonderful feeling of being around young children, there’s nothing like it.
Daniel: He’s at a developmental stage where practically every day there is a new thing. Certainly, every week there is a new thing. And he is putting together really quite complicated sentences. How did you just do that? That was like a future conditional…what’s going on?! “When we will have gone there and done that, I can do…”, you’re three, stop it!
Clare: Brilliant. Last thing, where can people find you, and do you have anything coming up that you would like to plug?
Daniel: They can generally find me on Twitter, I mostly try to be nice. I lapse but I mostly try to be nice. I am at dannorth.net, I’m a very infrequent blogger. I’m doing quite a few talks at the moment. I spoke at Craft earlier in the year. I’ve got a GoTo coming up, I’m at Jacks London. All of these are remote events, we are trying to get some more hybrid things, but it won’t be for a while.
On my newly minted website, which is now running on Hugo, a new flat, static website which I’m very happy with, having moved away from WordPress, I have a section there for upcoming talks which I have not populated, which I will go and populate hopefully this week with several upcoming events.
Clare: Brilliant.
Daniel: The easiest way to get hold of me is Twitter. I’m on LinkedIn, I’m really bad at responding on LinkedIn but I’m around.
Clare: On Twitter, you are tastapod or tasteapod – what the hell is that word?
Daniel: It’s @tastapod. I think enough time has passed that I can talk about it now. What it was, this is probably about 20 years ago, we were playing a game of made up word Scrabble?
Clare: I haven’t but I want to.
Daniel: It’s the most fun ever. It’s a collaborative game. It’s like Call My Bluff. You’ve got tiles, you’ve got a Scrabble board. You put down a word. The only thing about the word is it has to be made up. You play the word for however many points, like in Scrabble, then you have to give it a definition. If everyone else thinks that definition suits that word, you get the points.
Clare: I like it! I want to go and play it right now.
Daniel: Of course, the long game for made up word Scrabble is to get a word into regular usage.
Clare: Because Kwyjibo is the obvious one. Kwyjibo is a word played by Bart Simpson in the Simpsons. He insists that it is a word, it’s not a word but it’s such a great word, and such a great Scrabble word. I’m a big Scrabble fan, I play a lot of Scrabble and I love to play high scoring words. Kwyjibo is great because it has a K which is 5 points, W is 4 points, J is 8 points, B is 3 points, it’s got all these amazing letters in it. It’s a great Scrabble word and it’s not real. But in our house, it is real. We are allowed to play Kwyjibo.
Daniel: Yes, I think you’re allowed. Same as the famous episode where Bart describes that he has been beaten up again. He says, “He’s just so pugnificant.”
Clare: That’s a good word, yes.
Daniel: Then the caretaker says, “Don’t be stupid, pugnificant is not a word.” Then the headmaster says, “Come on, pugnificant is a perfectly chromulant word.”
Clare: Very good.
Daniel: So, I’ve used chromulant in business documents. You know, “I think this is a very chromulant approach.”
Clare: Very good. I’ve just realised that there will be a small number of people out there who are like me and are completely fixated on how the hell you spell Kwyjibo. So, just for the people who like me, like to know how things are spelt, it is K-W-Y-J-I-B-O. There you go, Kwyjibo.
Daniel: What is a kwyjibo?
Clare: I don’t know. I would have to think about that. I never have. I was quite happy for it to simply be a word that existed in splendid isolation, without having to have a meaning. It’s just the word that you play in Scrabble.
Daniel: So, the next time we speak, I want you to use kwyjibo in a perfectly chromulant sentence.
Clare: I think it is quite likely to be a widget.
Daniel: Like, “Can you pass me the kwyjibo?”
Clare: Exactly, yes. It might also be quite specifically a remote control for the telly.
Daniel: So, “The PlayStation Kwyjibo has gone missing again.”
Clare: Yeah.
Daniel: This is now starting to work for me. A tastapod is an ironic word. It’s a small potted plant, either bought for or received from an elderly, typically female relative, or procured from a petrol station. Like a poinsettia at Christmas is like your canonical tastapod. It’s from taste, tasta, the first part is tasta from the same route as taste. Pod is a middle English word for pot. So, it’s a tasteful pot, you see, a tastapod. So, it is any small potted plant that you buy for or receive from an elderly relative.
Clare: Did it originate in a game of —
Daniel: I played it in a game of made up word Scrabble. The reason I started using it in real life is because it has eight letters. You can say it over the phone, and it is spelled how it sounds, so it’s great for domains. I’ve got tastapod.com. Every time I need to register somewhere, and it says, “What’s your username?”, I always use tastapod because I made it up. Either it says, “Sure, that’s available.” Or it says, “That’s not available.” I think, that’s probably me then, I’ve forgotten I registered. I go, “Forgot Password”, and it goes, “Here you are!”. That’s why I am Tastapod everywhere, on Twitter and all kinds of other places.
Clare: Fantastic.
Daniel: I’m Tastapod on GitHub, so there you go.
Clare: I love it.
Daniel: My favourite is Apial.
Clare: Apial?
Daniel: An apial is a little bit of hair that sticks up at the top when you brush your hair. It doesn’t go in any of the directions, it just sticks up. That’s your apial.
Clare: That’s good, I like that.
Daniel: “Clare, you’ve got an apial.”, “Ooh, thanks!”
Clare: It’s been so good to speak to you Dan.
Daniel: A real pleasure, lovely to catch up.
Clare: Thank you for coming on the podcast.
Daniel: Thanks for having me.
[Music Sting]
Clare: As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
So, early on in Daniel’s career, he came up with the idea of Behavior Driven Development, otherwise known as BDD. But he now prefers to talk about Example Guided Design, which is his preferred name for what used to be called Test Driven Development, or TDD. The idea of TDD being guided by tests goes all the way back to the famous book on TDD, often referred to as the GOOS book – based on the initial letters of the title words – by Steve Freeman and Nat Pryce. But are they even tests? So Daniel’s new definition of what testing is, is that its goal is to increase confidence for stakeholders through evidence. And it’s really important that you start with the stakeholders. They know stuff you don’t, and might care about stuff you hadn’t even thought of.
And in fact, it’s not even increasing confidence so much as reducing uncertainty. So unit tests are not tests so much as examples, hence replacing the term Test Driven Development with Example Guided Design. And if you rely purely on these examples to give you confidence in your system, you’ll have a false sense of confidence. They tend to be about functional correctness, which is great, but you should also be thinking: Who are the stakeholders? What is their interest? What evidence do they require? And that will lead you to think about performance, availability, resilience, observability, compliance, legal implications, downstream load on other systems. And don’t just think about how fast your tests can run, do impact analysis and use your testers to teach their testing mindset to the rest of the team. Use the scientific method to try and disprove the hypothesis that everything is OK.
OK. Stick around for extra content!
[Music Sting]
Clare: Coming up is our Making Life Better section. And in this edition, we talk about supporting people who are struggling. So I just wanted to give a quick trigger warning that we do mention suicide. If you’d rather skip this bit, you can fast-forward to around the 40 minute mark, where you’ll find us talking about time management.
[Music Sting]
Jack: Working in the public sector means that at Made Tech, we really care about making a difference. So for this final Making Life Better segment, me and my colleagues will be sharing small pieces of advice to make the world a better place. Today’s advice comes from Chris Wilson, one of our Client Principals who has some advice on helping people who are struggling: Be a good listener and offer to listen.
So Chris, tell me a bit more about what that means.
Chris: Yeah, so it’s been a tough year for a lot of people for different reasons over the last 18 months. And I’ve always offered to try and support people who are struggling with a number of things. And I try and do things like food bank drop-offs, helping to provide food parcels to neighbors if needed. Also offering to be a sounding board for those struggling with depression or lack of social contact. I think not being able to see family and all other manner of things can affect your mental health and wellbeing. And I’ve unfortunately had some male friends who, um, who are not with us any more. Um, have decided to take their own lives. And outwardly they’ve seemed perfectly fine and enjoying life. But inside they’re being torn apart by the daily struggle. I found that quite difficult to swallow. That, you know, right there under all of our noses, someone’s been struggling so much with life, and been too proud or embarrassed to ask for help.
Chris: So I regularly try to connect with friends and family to let them know I’m available. I’m happy to listen. I can offer advice or I can be there just to be a non-judgmental sounding board. And sometimes people don’t want to hear your solution. They just want somebody to talk to and for you to listen to them. So that’s what I try and do. I think you’re helping people get things off their chest. It makes a huge difference to allow someone to just talk aloud about their feelings without thinking they’ll be judged.
Jack: No, I absolutely agree with you there, Chris. Sometimes it is just knowing that there is someone there who will listen and having that sort of little olive branch of noticing that like it’s not going to solve the problem, but it’s a lot worse to be alone and sad than to just be sad. And so sort of reaching out, having those moments, are really really important. And I think that’s wonderful that you do that.
Chris: Yeah, that’s right. And I’m also part of a large WhatsApp group, that a bunch of old friends are part of. So that can be people that I haven’t seen for a long time or some people I don’t even know very well, but they’re friends of friends. So it’s been a great opportunity for some of us to reconnect after such a long time in silence. And, you know, we use that to check in with each other from time to time. Share a few memes and jokes, or old photos of holidays or events that we don’t want to share with the wider public, you know. And I think that’s really helped us all. So from my point of view, it doesn’t take much to just kind of reach out to someone and tell them it’s OK not to be OK. And to be somebody who they can talk to without feeling judged.
Jack: Chris, that’s absolutely fantastic mate. I really appreciate you taking the time to give that advice. I think it’s something that we can all sometimes do with reminding ourselves that it doesn’t take much just to sort of, send a quick “How are you?” and remind people that you’re still out there.
Chris: No problem. Thank you, Jack.
[Music Sting]
Jack: Every other episode, this last short segment will be dedicated to Hack of the Month, where one of our colleagues and in the future, our listeners too, will share a life or a work hack. Our guest this month is Owen Pigott, one of our senior engineers, who’s going to be talking a little bit more about time management. Ensuring focus time each day that is uninterrupted. Owen, do you want to elaborate a little bit more on that one?
Owen: Yeah, sure. So thankfully this is something that’s now becoming a lot more obvious and mainstream in the workplace. You’re seeing it in emails from Microsoft, where they provide you with an analysis of your time using MS Teams. And in other areas, we’re finally realising that those gaps, those 30-minute or 60-minute gaps between meetings, aren’t anywhere near as valuable as turning them into one big gap of three hours and trying to keep the meetings outside of, sort of your core work. Which isn’t just software development, it can be all sorts of things. It’s been proven that we need a certain amount of time to ramp up. And if you’ve only got a small gap between meetings you ramp up, almost get going, and then you’re back into the other meeting. So it creates a lot of dead time. So I think that everybody should try and get, I’d say at least two-hour gaps where they’re able to work in a focused manner on what they’re trying to do.
Jack: That’s excellent. So do you use any tools in particular or do you like mark it in your calendar – just some general advice that anyone could apply?
Owen: So, first thing I do when I start my day is check my calendar. And then it just gives me this insight into what’s happening. You can obviously put in blocked-out time in your calendar. That’s a really good one, where you just put yourself “tentative” to meetings. And that can just make people question it a little more, if you’re invited to a meeting that might be too general. Or they’ll ask, you know, who’s really needed for this meeting. It can save time as well, because then you’ve got meetings with a lot less people in them. Because people are really questioning who’s required in them. So it’s good for other people.
Jack: Absolutely. And especially when like zoom fatigue is a genuine epidemic at the moment. So I think that it’s incredibly valuable advice. Well thank you very much for that Owen, and have a wonderful day.
Owen: Cool. Thank you.
[Music Sting]
Clare: And that’s the end of another episode. If you’re enjoying the podcast, please do leave us ratings and reviews, because it pushes us up the directories and makes it easier for other people to find us.
Speaking of which, we’ve had three new reviews since the last time. Thank you to VG365, who finds the podcast easy to listen to and informative. Also Koanstudy, who says if you usually avoid corporate podcasts, it’s worth making an exception for Made Tech’s efforts, which is really nice to hear. And then somebody calling themselves “I’m not drunk you’re drunk” says that the podcast is honest, genuine, and eye-opening. If you want to see those reviews in detail, you can go to the Apple Podcasts app.
I’ve got a few talks coming up. You can see the details on my events page on Medium, which is linked to from my Twitter profile. And you can find that at @claresudbery, which is probably not spelled the way that you think. There is no ‘I’ in Clare, and ‘Sudbery’ is spelt E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter @madetech, M A D E T E C H.
Do come and say hello, we are very interested to hear your feedback and any suggestions you have for any content for future episodes, or just to come and have a chat.
Thank you to Rose, our editor, Gina Cady, our virtual assistant, Viv Andrews, our transcriber, Richard Murray for the music – there’s a link in the description – and to the rest of our internal Made Tech team; Kyle Chapman, Jack Harrison, Karsyn Robb and Laura Plaga. Also in the description is a link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings. Thank you for listening and goodbye.
[Recording Ends]
Back to the episode
