Support for the Greater Than Code podcast comes from O’Reilly Fluent and Velocity Conferences, coming to San Jose, California June 11th through 14th. From ops to apps, Velocity and Fluent tears down silos, enabling and fostering the kind of cross-department collaboration essential to driving innovation and speeding product delivery. Best Price ends this Friday, March 30th. Save up to $839 using code GTC20. That’s GTC20 which stands for Greater Than Code 20. Learn more at OReilly.com/BetterTogether.

JAMEY:  Hello everyone and thanks so much for tuning in to episode 73 of Greater Than Code. I’m Jamey Hampton and I’m here with my great friend, Jessica Kerr. 

JESSICA:  Good morning. I’m excited today because our guest is Dan North. Dan is the originator of behavior-driven development which Jamey just started at work two weeks ago, so that’s exciting. Dan was also the first technical hire for ThoughtWorks in the UK way back in 2002 and is best known for hiring Jez Humble who went on to publish the continuous delivery book. These days, Dan puts people first and finds simple pragmatic solutions to business and technical problems, often using lean and agile techniques. He also plays the drums at St. Paul’s Church in Kingston in Surrey, which is in England. Dan, welcome to the show. 

DAN:  Hi, Jess. Thanks for having me. 

JESSICA:  Okay, okay. So, we always start our show, for some definition of ‘always’, by asking you: What is your superpower and how did you acquire it?

DAN:  This is interesting. I think my superpower is improving things, is optimizing things. I realized recently – I’ve been in tech for over 25 years, so over a quarter of a century – and I’ve had one, possibly two good ideas in my entire life. And one of those is really derivative. So, I’m absolutely rubbish at coming up with new stuff. What I think I’m good at is helping other people grow an idea. So, if you come to me with an idea, I can help you make it awesome. And I realized this – [inaudible] at ThoughtWorks, I joined a small team in a trading firm as a developer. And we were writing some pretty cool trading systems, and really, really quickly, which was great fun. So, very technical work. So, we’re trying to build low-latency trading systems which means you’re trying to squeeze every last microsecond and nanosecond out of low-latency, Fastpass and all this kind of stuff. And it was a blast. And I realized after, I don’t know, a few months, I really wasn’t adding much. Yeah, we were writing good code and that was all fun. But the team was already fine. And so, I found that I was running around trying to make things better for them. And nothing mattered because they were already fine. So, I’d go and try and make things better with management and as soon as I pushed on the management doors, they flew open because they just had really brilliant management there. And I realized after about a year that none of my superpowers work, because the organization was really functional. So, it turns out my superpowers only work at really dysfunctional organizations and really dysfunctional teams. So, I guess I make the dysfunctional functional. 

JESSICA:  That’s interesting. You mentioned that you improve and you also used the word optimize. Are those the same thing? Are they ever in conflict?

DAN:  Ooh. Oh, I like that. Improve I think is motion towards often some kind of local goal. So, we could improve team morale. We could improve performance of a system. We could improve how quickly we get things into production. Optimize, I see as a system goal. So, it’s looking at something holistic and saying, “How do we optimize all of this in order to achieve an outcome?” So, if I were to for instance optimize for flow, like I want to try and get work flowing though a system, it may mean that some people will be less busy than they were. And that’s fine. So, if I’m trying to improve utilization, that’s – you know, I could improve utilization but it’s going to destroy the throughput of the system. So, I haven’t actually thought of those different things. But yeah, I think you can make lots of local improvements and you still don’t really get the overall win. Optimizing is about stepping back and seeing the whole. 

JESSICA:  That makes sense. So, optimizing is at a very high level, the whole organization. And within that, you improve locally. If you do it the other way around, it’s a disaster.

DAN:  So, yes. I’m aware that as I’m saying this, I’m kind of abusing the language a bit. So, I’m choosing to make those words mean those things. So, if you look at a lot of the [inaudible], talk about global versus local optimizations. So here, I’m using ‘improve’ to mean a local optimization and ‘optimize’ to mean a global optimization. What I will say though is this: is when – particularly in the context of kaizen, which is a Japanese words which means continual improvement, lots of little improvement – we tend to think of an improvement as a small movement. So, we take a system and we change it slightly and we make it slightly better. The kind of counterpart to kaizen is a thing called kaikaku, which – lots of people have heard of kaizen. Have you heard of kaikaku? No. It’s the less cool one. It’s the less well-known one. So, kaikaku means an abrupt change. So, if you think of – kaizen is a really good way of inching your way towards some local maximum. Kaikaku is saying, “Well, that’s great. But what about if we went right over here instead and see if there’s something more interesting over there?” 

So for instance, kaizen: I might have some traditional plan-driven, whatever way of delivering software. And I might say, “Oh, do you know what? If we were to be a little bit more disciplined about how we track time against our time tracking then maybe we might…” This is all kaizen. This is all trying to make your process slightly better as that process. 

Kaikaku is, “What if we threw the whole thing out and just started working on taking a single piece of work all the way through the system?” See, now that’s completely wrong. That’s completely not allowed. That’s completely counter to what we’re doing. And we try that. And do you know what? It kind of works. But we’re not sure about a whole bunch of the other things. Maybe we’ve broken some other things. But we tried this new thing and it works. And it doesn’t work that well because we’re rubbish at it because it’s new. But it feels like it has the potential to work a lot better than the old thing. So then we say, “Well look, let’s run with this thing for a bit.” So, we do lots of little bits of kaizen, little bits of kaizen. And we suddenly find that we’re much better at this thing. So, you tend to find it’s some sort of yin and yang type thing. So, you get this kaikaku, this abrupt change, into a new way of being, into a new state, into a new model. And then kaizen is about, “How do you then tune that model?” 

But what we tend to do is we tend to obsess – in the west, this is – we tend to obsess about the kaizen bit, the little improvement bit. And we find that we get a little bit lost with the kaikaku. We kind of obsess about our process rather than saying, “Well, what if we step back? Are we even doing the right thing?”

JESSICA:  Can you do both of those, both at a high level and organization-wide level and at a team level?

DAN:  Yes. [Inaudible] And actually, that’s a lot of what I do these days. So, at a high level, a lot of my job is trying to convince typically very smart, very experienced, quite senior people that they have built a career around, become very, very good at, doing exactly the wrong thing. And that’s a really difficult pill to swallow. So, what we’ve done in the west again, is we’ve gotten really good at a thing called ‘cost accounting’. Cost accounting is the idea that an organization is made up of a number of units, typically departments or divisions or something. And each of those divisions either adds value, is what’s called a ‘profit center’ or it costs money, so it’s a ‘cost center’. And the goal then of each of those things is to, for the profit centers, my sales divisions, I want them to maximize their profit. And my cost centers, I want them to minimize their cost. So, if you’re in IT you’re a cost center. If you’re in operations, you’re a cost center. If you’re in infrastructure, you’re a cost center. If you’re in manufacturing, all of these things are cost centers. 

And so, what we have is a head of IT, a CIO or someone, whose job is to drive down cost. If you’re in sales, your job is to drive sales and increase profit. And so, you get the commissions and incentives and those kinds of things. That model works, or rather that model came into being, as organizations grew. Because what happens is when an organization goes above a certain size, above a size that will reasonably fit in your head – you can’t know all the things that are going on – you need to keep some kind of control over it. And that’s kind of the least worst model we came up with. This is like, middle of the last century. 

The lean approach to this, the kind of holistic approach to this is to say the enterprise, the organization, is about meeting some customer’s need. It’s about building some product or some service or providing something that meets someone’s needs that they’re prepared to pay for. And so, from that regard, everything in the organization really is building towards that outcome. So, there’s no cost centers or profit centers. There’s people doing value-adding work. And the idea is that everyone in the organization should be doing something that’s either directly adding value, directly on what’s called the value stream, so producing cool stuff, or they’re enabling people to produce cool stuff better. So, that’s the improvement piece. So [inaudible], all your functions. HR – they’re your people function – is about firstly getting hold of good people and bringing them into the organization. They’re going to be able to add value. It’s also about people happiness and making sure that people in the organization are working to the best they can. Likewise your finance functions are about making sure that where we need to spend money in order to produce value, the money’s available. And so on. 

What happens with a cost accounting world or rather the fallacy of the cost accounting world is like saying, “Where the smoke comes out the tailpipe of a car,” that’s like saying “Well, that’s where the money comes out or where the sales happens. So, let’s go after that.” Now, if I’ve got a lot of smoke coming out of my car, the chances are it’s not the tailpipe. The tailpipe is just where I first notice it, yeah. It’s probably somewhere else that I should be looking for that smoke. Likewise, we talk about the sales people are making all the money. No, they’re not. The sales people are taking money off people. The whole organization is making money. So, it’s that deep of a fallacy. So, we’ve got, as large enterprise, we’ve gotten really, really good at that cost accounting thing. And it turns out that when you get really, really good at that cost accounting thing, you destroy the ability of an organization to flow value. Any value coming out of the organization is in spite rather than because of those controls. 

JESSICA:  And those controls, you could do the kaikaku and jump your organization to a completely different way of looking at the flow of value and therefore money. But yet, you’re embedded in an economic system that demands cost accounting. 

DAN:  Right. And this is where it gets interesting. So, in 2005 I think it was, a lovely Norwegian chap called Bjarte Bogsnes (that’s a great name) who was the CFO I think of Statoil – so this is the Norwegian state oil company, which is a 50 billion dollar organization. He’s looking around the organization and he says, “Do you know what? I recon we spend conservatively 10% of our effort each year on budgets.” We spend 10% of our effort each year planning for budgets, negotiating budgets, horse trading after budgets, and that thing you do at the end of the year where you’ve got to spend all your money otherwise you haven’t spent all your money and you don’t get all the money next year – which by the way is a great time of year to be a consultant. People like to book courses right near the end of their financial year. It’s a ridiculous way to manage money. And his metaphor is, he says, “It’s like having a bank that’s open two weeks of the year.” if you don’t get your predictions right, then you’re basically stuffed for the next 50 weeks. And so, as CFO, of course he’s got some levers. So he said, “We are going to stop having budgets.”

JESSICA:  [Laughs]

JAMEY:  Okay. I’m listening. 

DAN:  Was pretty much exactly the noise that the entire board made when he said that. And he said, “We’re going to replace this whole budget charade with some really simple rules.” He says, “The first rule is everyone gets a checkbook.” The CEO, the head of marketing, programmers, janitors, dinner lady, everyone in the organization who has any input, any [inaudible] organization gets a checkbook. You all get to spend money. The second thing is this: he says, “Spend it like it’s your own.” The way you spend money is as though it were your own budget, your own funds. And he says, “The third thing is that all the spending is transparent.” So, you can buy what you like but from anywhere else in the organization, I get to see what you’re buying. And what that did is it replaced practically all of the policy. 

So, imagine you’ve got a travel policy. And I’ve worked at consulting firms where if you travel under so far, then you have to fly economy. You have to fly coach. If you’re going above a certain whatever, then you’re allowed to fly – just that kind of stuff. They didn’t have that. They just said, “Spend it like it’s your own money.” So say, Jessica and I are both flying. We’re both in London. We’re both flying to New York for a conference. And I decide I’m going to fly business and Jess decides she’s going to fly coach. 

JESSICA:  Economy plus, please. 

DAN:  Well, okay. So, then someone says, “Why did you do that? Dan, justify yours. And then Jess, you justify your economy class.” And it turns out that I’m flying in on the Sunday night red-eye and I’m going step off the plane and I’m going to go straight into a meeting. 

JESSICA:  Right.

DAN:  And you know what? I should probably get some sleep. So, that’s a good call. Jess has got friends in New York. She’s flying out on a Friday. She’s going to spend the weekend there. She’s happy to fly coach plus. The reason she’s flying coach plus is she’s got a bad back and so she doesn’t want to be in those cramped seats. And that’s completely legitimate. So, both of us, we can justify that spending. It makes sense to have spent the money in that way. So you know, I’m not your mum. I don’t need to check up on you. I trust you. And so, they did this. And they call it ‘beyond budgeting’. And so, in 2005 he just dropped budget. And I know some folks at Statoil. And it wasn’t all rosy and joyful and whatever. But it was an awful lot less bumpy than people expected. 

JAMEY:  Interesting.

DAN:  And the following year, they didn’t lose any money. In fact, they made money. And practically every year since, they’ve been doing pretty well. A few years ago, they found another shelf of oil under the North Sea and they’re not worth 90 billion dollars, which is handy because that’s how oil works. But yeah. So, they were worth of pioneers of this model called beyond budgeting which is based on, if you go back and follow – everything has a precedent, right? - is from the ‘The Goal’ from Eli Goldratt and he calls it ‘throughput accounting’. And in throughput accounting, you basically – it’s much, much simpler than cost accounting but no one does it. So, throughput accounting, there’s three numbers. That’s it. The whole of throughput accounting is three numbers. 

There’s inventory, and inventory isn’t stock like you imagine inventory in your head. It’s a number. So, it’s how much money you’ve spent on things you’re going to turn into product. Throughput is how much money you’ve made by selling product. And operating cost is how much it costs you to turn inventory into throughput. That’s all of the numbers. Brilliant. So then, the goal of the organization is to minimize inventory, maximize throughput, manage operating cost. If you’re doing that, you win. And that means that you can now have holistic metrics for all those things. I can have local metrics for all those things. I can start looking at, if I drive down my operating cost over here, I can do that but it increases inventory over there. And that’s one of the things I’m trying to keep a handle on. So now, I have to make trade-offs. And so, it starts connecting up the right people in the organization who should be talking to each other. 

The problem, and you kind of alluded to it with your question, is although that’s glaring common sense and a much, much simpler way to run an organization, and it turns out a much more sane way to run an organization, you can’t just do that. You have to also produce all of these cost accounting numbers by law. Because if you’re a publicly traded company, every quarter you’ve got to trot out the same nonsense that everyone else does because then people think they can compare apples to apples. So, you still have to have your EBITDA and a whole bunch of other acronyms. They’re called GAAP, generally accepted accounting principles. And if you don’t produce those numbers, you get in trouble. So yeah, there’s the set of books that you’re running the organization from with really, really simple numbers in, and the ridiculous charade of numbers that you have to produce because everyone else is producing them as well.

JESSICA:  So, that’s good money for the accounting consultancies.

DAN:  Oh, yes. And the auditors. The auditors love all this, yeah.

JAMEY:  I’m curious about this model that you described at this company. It sounds really interesting to me. But I’m curious how it’s affected by demographics. Because we hear a lot about as an example, one of the problems behind the wage gap issue is that you’re seeing women who aren’t negotiating as aggressively as men, just as one example. And I’m wondering if putting a policy like this in place, like what would you have to do to make it fair? When I hear, “Spend it like your own money,” I’m thinking people who historically have not made as much money and aren’t as confident and senior in their careers having real insecurities about that. And I’m wondering if that’s something that they thought about or that you’ve thought about and if there was anything related to that built in at all.

DAN:  Yeah, I think that’s a great question. It’s a really relevant, pertinent topic right now as well. So, one of the things I’ve experienced in organizations that tend to use more flow-based metrics, and this is in terms of tracking work rather than tracking things like money – and this may be cultural. It may be intrinsic. It may just be I’ve lucked out in terms of where I’ve worked and the other impacts I’ve managed to make – you tend to get a more equitable culture coming out of that. There’s less to hide behind. So, in a typical cost-accounted organization, you get fiefdoms. You get the head of testing who owns all the testers and the head of development who owns all of the developers. 

JESSICA:  Oh, the empire builders, yeah. 

DAN:  The empire builders. And then within that you’ve got the kingdom of Java versus the kingdom of C# and the .NET-ers and the Linux-ers. Rather than think in, “How do we generate value here?” it’s like, “How can I build my empire?” That tends to be a much more male-centric model. And I suspect that’s a more male-centric model for exactly the reasons you’re saying, which is – so, let me break out, make sure I’ve heard what you said. And if I haven’t, please correct me – is some of the studies I’ve seen or heard about are that women in general – and I think it’s not so much they’re less assertive about pay, because I thought it was that. It’s that’s a second-order thing. The main thing is that if there’s a man and a woman looking at the same role, and again I’m massively generalizing here, if there’s a man and a woman looking at the same role, the woman will tend not to apply for that role until she’s almost over-qualified for it. She wants to be super confident that she has the skills and the capabilities to carry out that role well. Where the male candidate will kind of wing it. So, they will tend to put themselves up for roles that they don’t necessarily know they can do but they reckon they could probably take a good stab at it. 

JESSICA:  Men get hired for potential and women based on proven experience, relatively. 

DAN:  I think that’s one of those post-rationalizations. Do you know what I mean?

JESSICA:  [I don’t know].

DAN:  Because of that, because that’s a, “Yeah, well. You know. It seems to be that’s what we do.” I don’t necessarily think that is. I think that’s a perception of what we do. And so, the reason I’m [inaudible]

JAMEY:  I disagree with that. 

DAN:  Oh, go on. 

JAMEY:  I think that that is a real thing that a lot of people have experienced. And then because if I hear that someone else I know experienced that, then that creates what you’re describing, this fear of applying for things because you have this perception that will happen to you. But this perception that it will happen to you isn’t based on something internally. It’s based on experiences that other people have had. That’s how I feel about it. 

JESSICA:  It’s all a spiral, right? The one feeds the other, feeds the other. And they make each other more true.

JAMEY:  I agree.

DAN:  You’re right. It almost doesn’t matter whether it’s true, right? 

JESSICA:  Yeah.

DAN:  Believing it’s true makes it true. 

JESSICA:  Yeah.

DAN:  Exactly what you’re saying, is that because you’ve heard that that happens, you’re now primed that that’s likely to happen to you. 

JESSICA:  Things are the way they are because they got that way. 

DAN:  Yeah.

JESSICA:  The interesting question is why do they stay that way?

DAN:  Well, and this is it. And so, what you end up with is resilient systems where that becomes a status quo. And what I’ve found is when you have more transparency, when you have a more of an obvious shared common goal, which is flow of value rather than localized goals which is, “What’s my empire looking like?” then I’ve certainly found that it’s easier to both identify that behavior, that lack of equity, and also intervene. Mostly I’m there as a fairly senior, fairly well-regarded, middle-aged middle-class white male. 

There’s a lovely chap I met at a conference a couple of years ago. His name’s Anwan. And he introduced me to the concept of lending privilege. I hadn’t heard of lending privilege before. So, because I have privilege, because I fit all, I tick all of those demographic boxes and that means that when I go into certain situations I automatically have privilege, if I’m aware of that, it’s mine to lend. So, if I’m in a meeting in and someone isn’t being heard because she’s female or isn’t feeling like she wants to speak because there’s lots of alpha behavior going on, I have the right by being white, middle-class and male, to say, “Hmm. Claire, what do you think?” And that gives her the floor, or something. And I think there’s a duty of care – I was about to say ‘responsibility’. I think it’s more than that. There’s a duty of care of anyone. And it’s all relative, right? And any one of us will find ourselves in much more privileged positions than others from time to time. And we have the duty of care to lend that privilege. Any one of us can be sensitized to realizing when we don’t have that and may be calling it out. 

And what I find is, to answer your question, is when you’re in an organization, when you’re in a construct that is more about meeting a holistic goal, so everyone lining up behind the same thing, I find that it’s a lot – two things. It’s harder to hide behind the old construct, the old guard, for the currently privileged. And it’s also, I found it’s easier to spot when people are underplaying their hand. So, exactly your thing about maybe someone wouldn’t feel that they should be allowed to travel in business or whatever. Because then if I notice that they’re not traveling in business – which I’m allowed to notice because guess what? It’s transparent – then I might say, “Do you know what? Actually Jess, I saw that you traveled coach there. Great for saving a few bucks. But you need to take yourself seriously. And you need to take your self-care seriously. And I would rather you spent a few bucks on that flight and got there refreshed and feeling good.” And you can do some of that direct intervention type coaching because you’ve got the data. 

JESSICA:  So, while there is danger in not having specific rules in that certain people feel like they can do business class and other people may not, it’s better than the old system with its lack of transparency. And we can do the kaizen thing of gradually improving. And because of the transparency, everybody has the opportunity to do the kaizen thing, which includes the opportunity to lend privilege. 

DAN:  Absolutely. A real example: one of my clients is just starting to look at shifting the way they reason about work and measure work towards things like lead time and value. And one of the things that they see as a real hard sticking point – this isn’t a hypothetical thing. This is a real situation they have – is that there are tons and tons of KPIs all over the organization that have just emerged. 

JESSICA:  The key performance indicator?

DAN:  Key performance indicators. These are local metrics. So, I was talking to an infrastructure guy who looks after data centers and whatever. And he has a metric to reduce the number of operating systems in use to X. and he has another metric to reduce the number of – and you can see all of these local cost targets that we have no idea what impact that’s going to have elsewhere in the organization. Something that will be dear to probably both your hearts I would imagine is the person, typically the person or the department in the organization that buys your laptop is a procurement department. And that procurement department has targets, typically cost-saving targets. If it can shave a couple of hundred bucks off your laptop and give you a crappier laptop, they get a bonus. 

JESSICA:  And you get less work done, even though it’s harder to measure. 

DAN:  Now let’s scale this, right? Let’s make you bank or an insurance firm or a big retailer. There’s literally tens of thousands of you and nine people in procurement. So, the nine people in procurement got a bonus. Epic. Go procurement. 24,000 people have a crappy laptop, can’t connect to work, don’t get work done, get less stuff done, all of that. 

JESSICA:  The IT department had to hire nine more people to deal with the problems with those laptops, which made them happy because then they have a larger empire. 

DAN:  Yeah, except that now their cost overhead has gone up. So, what they actually did was they hired in nine more consultants from a vendor because that’s a cost in a different column. 

JESSICA:  Oh, yeah. Totally. 

DAN:  This is what happens, right? Because the money’s in different parts. For instance, at the end of the year – so one of my clients routinely at the end of the financial year sheds hundreds, if not thousands, certainly hundreds, of really, really smart contractors. External developers. And these people may have been with your organization for quite a few months. They’ve gotten to know these systems. They’ve been adding value. And they ditch them, because at the end of the year, they have to be net zero or something. The following week, because then you budget your stuff, you have to go out and hire a lot more. 

JESSICA:  Oh my gosh. And spend six months spinning them up. 

DAN:  Oh, yes. And this is normal. We think that this is normal. 

JAMEY:  Oh my god. This is just – you’re making me so glad that I don’t deal in any finance stuff. 

JESSICA:  Yeah. Jamey, how big is the company you work for?

JAMEY:  I think there’s like, 14 of us now at the whole company. 

JESSICA:  Yeah, we have 13 at Atomist currently. 

DAN:  That seems like a pretty sweet spot. I think [as long as you] stay below that. Well no, being serious for a minute. I think, so the inflection points that I’ve seen is around about, up to about 20 is a group of mates, a group of friends hanging out. And then around 30 to 50 you become a company. And you realize that you’ve got to start doing some stuff a bit differently. And then if you make it past about 30 to 50, the next interesting one is about 120 to 150. And if you make it past there, you get to 500. And then you start all the big corp stuff. 

The interesting thing is how you navigate those transitions. Because typically what happens is as you hit those inflection points, you specialize. And that’s where you get your IT department, your sales department, and your development, and your whatever else. Whereas a lean organization, when they do specialize, because they will need to specialize, they specialize along value streams. So, this group of people runs this set of services. And this group of people meets the needs of this set of customers. So, you’ll still get those seams in the organization. But the seams in the organization are now aligned with the way value is trying to flow through the organization. So, as it grows, you still have the organizational effectiveness of what feels like a smaller firm but at scale. 

And this is a thing that Spotify famously was solving for. And Henrik Kniberg, I don’t know if you’ve had Henrik Kniberg on this, on your podcast, but if not, he’s a fantastic guy to speak to. He was very much involved in helping them be the shape they wanted to be. I was working with them for a little while as well, back in – when they were like a few hundred people. And I said to them, “So, what are you trying to do?” And they said, “Oh, we’re 300 people. We want to be 3,000 people.” That’s a crazy aspiration. Why do you want to be 3,000 people? And they said, “Well, we stream music. We bring creators of music together with consumers of music. And that’s our product. So the enemy, if you like, the competition, is Apple, is Google, is Amazon. So yeah, we need to be 3,000 people to go toe-to-toe with that.” And I said, “Yes, you probably do.” You’re picking on some quite big people there. And what they did which I thought was brilliant was they said, “Okay. Let’s imagine a 3,000-person organization. What shape would it need to be if it were to have” – and the two things they went after, they called it autonomy and alignment. 

So, autonomy is a small team, half a dozen people, can get good work done. Not just that they had independence, because that’s easy. That’s just anarchy. That’s people running amok. Autonomy is that not only do we have permission to do what we want to do, we kind of know what everyone else kind of does, so we know that we can make choices that are kind of aligned with what they’re going to be doing as well. So, there’s a ‘communications’ piece. There’s a ‘communities of practice’ piece. There’s a “What does good look like around here?” piece. And so, they call that autonomy and alignment. And they came up with this idea that the fundamental structure in the organization was going to be what they called tribes, which is essentially a bunch of people along a value stream. So, these are people providing value to a customer. Or as the organization grows, they’re providing value to other teams. 

And across the organization, the dotted line, was what they called guilds, which is basically communities of practice. So, all the Java developers across the whole organization, whatever they’re doing, are connected to each other. And then the unit of execution if you like is what’s called a squad, which is a little bunch of people. And there’s all different kinds of squads. And the squads form around the work. And they make the work go away. And that model, and Henrik talks about this a lot – he says, “Do not copy our model. Do not copy our model. It probably won’t work for you.” He says, “It almost doesn’t work for us.” He says, “Copy what we did.” The question they asked themselves was, if we were to have a whole [inaudible] little teams that were going to be autonomous, how could we do that in a way that they were aligned? 

JESSICA:  Copy the question, not the answer.

DAN:  Boom.

JAMEY:  That’s so smart. 

DAN:  And everyone goes, “Oh, we’re using the Spotify model. We’ve got tribes and guilds and squads.” And I’m like, it’s like 42. It’s like, “Right, we’re implementing 42.” Brilliant. Did anyone ask what the question was? “No, we don’t need to. We’ve got the answer right here.” So, everyone goes off to squads and guilds. I know Jess, you work for an entirely distributed company whose secret sauce in terms of flow was everyone paired even though you were distributed. 

JESSICA:  Oh, at Outpace. Yeah, that was great. 

DAN:  Now, the org structure there, the way you aligned yourself and created autonomy and alignment there was completely different. And it worked for you. You asked yourselves the same questions. If we’re all sitting at home with headsets on, how do we all know what we’re doing? How do we stay aligned?

JESSICA:  Right. 

DAN:  If we’re delivering things to different clients at difference cadences, how do we have that autonomy and still know what good looks like? Still have, if I look at anyone’s Clojure code, it looks the same as anyone else’s Clojure code. And you iterated on that. And some of it works and some of it didn’t work. And the stuff that didn’t work, you threw out and tried something else. 

JESSICA:  Yeah. And currently at Atomist, we have some Clojure people and we have some people working in TypeScript. And the two teams have different ways of aligning. One way is a more open source style way, because we have a couple of the originators or Spring working on this. And the way to maintain alignment and keep up with what people are doing is to check out all the commits. You come in the morning and you’re like, “What happened in Australia while I was sleeping?” And the other team has closer timezones than Australia [inaudible] and they like to align with more meetings and more… 

DAN:  Right.

JESSICA:  Verbal talking synchronously.

DAN:  And let’s say you were going to scale that. And you said, “Do you know what? We need to double the number of TypeScript people we have.” I suspect the fact that I’ve just asked that question, you’re already in your head, you’re thinking, “How would we onboard them? How would we get them writing the same kind of code the other are writing?” You’re already thinking through ways of maintaining that alignment.

JESSICA:  Right. Yeah. Can we hire people that will be able to work with our current way of maintaining alignment? Which is not everyone. 

DAN:  Yes. And that becomes part of the – even the recruiting process, let alone the onboarding. I don’t know if this is still the case, but GitHub the company used to do their interviewing over IRC, over chat. And the reason they did that is because that’s how most of the comms works. So, there’s no point having a face-to-face series of interviews if then we’re going to see you once a quarter, and all the rest of the comms is going to be pull requests, right? 

JESSICA:  Yeah. That’s interesting.

DAN:  So, let’s start [35:12] on. They also, I think it was them or maybe another distributed company, where they have – it may even have been Outpace – they have a shared jukebox. So, everyone’s always listening to the same music. It’s like being in an office. And someone puts on a song and they go, “Oh [35:25]. Radiohead. Haven’t heard that for years.” And you get that kind of, that sense of connectedness and camaraderie because you’ve got some of those norms. You say, “Well, let’s all share music. Let’s all have the same music going on in the background.” 

JAMEY:  We actually tried that exact thing and it’s pretty cool. We all listen to the same music. And it was funny, because I liked everybody else’s music and I was like, “Oh, this is so good. This is so interesting.” And then when my music would play I would be like, “Oh, this is just an exercise in being self-conscious about your own music.” 

DAN:  I [did] that, yeah.

JAMEY:  So, it’s just like being there in person.

DAN:  It really is. And you put on something you think is amazing and it just kills the vibe. And you go, “I did that.”

JESSICA:  [Laughs] Yes, yes, yes.

DAN:  I was working at a trading firm. This is a confession. So, I worked in this trading team and it was a very, very high-performing team. So, you’ve got developers sitting with traders. And literally you write code, you run that code, you trade against that code, and you look at your P&L. And if the P&L doesn’t go in the right direction, you try a different code. It was a very, very immediate and very short value stream. And we’d have music on during the day when they’re trading and whatever. And one day I just had, in my head I’ve got to listen to Chilis. I’ve got to listen to ‘Under the Bridge’. And I put ‘Under the Bridge’ on and I was just thinking, “What a rocking tune.” It’s really not a rocking tune. When you’d just been listening to something pop-y, put on ‘Under the Bridge’. It’s a buzzkill.

JESSICA:  Aww, [dun-dun-dun].

DAN:  It’s just everyone looks at me and went, “What did you do?”

JESSICA:  Try different code.

DAN:  Oh, and I’m going, “Oh, come on. I’m [37:01].” “Come on. It’s a crying tune.” “Yes it is. But not for now.”

JESSICA:  Context, again. 

JAMEY:  I played a song. It’s a very catchy, upbeat song that used to be on the radio, but it’s called ‘Kill my Boyfriend’. And I was just like, “Oh, I like this song. Maybe other people will like it.” And I put it on and it started playing. I played this song on Valentine’s Day.

JESSICA:  [Laughs]

DAN:  [That’s beautiful.]

JAMEY:  And everyone was messaging me like, “Are you okay?”

DAN:  Is this a cry for help? Jamey, speak to us. 

[Laughter]

JESSICA:  Okay, okay. Okay, okay. Before we run out of time. You mentioned that you had a few good ideas in your life. Was behavior-driven development one of those?

DAN:  So, yeah. I think BDD yes, is one of my not-very-many good ideas. And as I say, that’s entirely derivative. And it’s very much standing on the shoulders of giants. So, it started out really as I was so excited about TDD. It’s one of the things, there’s been a couple of really obvious inflection points I think in my technical journey. So, BDD is entirely derivative. It started out, I was really, really excited about test-driven development. There’s been probably a handful of what I consider real inflection points in my technical journey. Refactoring was one. Martin Fowler’s work on refactoring, the period in my life when it went from being a thing that I just sort of heard of or read the book to becoming muscle memory. And that’s probably about a five, six, seven-year period. It really, I think we don’t talk about refactoring enough and the power of it and the importance of it and the significance of it. 

I guess I cut my programming teeth on C. And with C code, the metaphor – or not even the metaphor – the presenting symptom, if you like, that I look at is source control. So, C code is file-oriented. And essentially what you would do back in the day is you would write some code and you put it to one side. And you’d write the next bit of code and put it to one side. And you kept on doing that ‘til you had all the code and then you ran it. And that meant that you could use a very straightforward file-oriented source control system like CVS and that was fine. Then refactoring. 

And one of the apocryphal stories of its origins is Ward Cunningham working on a Smalltalk system, which is kind of like a precursor to domain-driven design. He said, “What if we named all of the properties in these objects as the labels that we want on the screen?” So, actually display it on the form. Because then there’s less code, right? You just take the labels of the name, the properties of the object and that is your screen labels. And someone on the team said, “That’s a great idea, Ward. But we often want to change the names of the labels on the screens. That happens quite a lot. So, what are we going to do?” And Ward said, “Well, we’re going to have to get really good at renaming properties.” And this is like, ‘…refactoring’. So, that was one of the big things for me, was – and it’s not necessarily the mechanics of it. Again, it’s that mental shift. It’s that kaikaku moment where you say, “Wait a minute. Code isn’t written and put to one side. Code is malleable. Code is a living thing that I can mold.” And you go from the metaphor of code is lego bricks to code is clay. And you start thinking of yourself as manipulating code. That was one of my big epiphanies, if you like. 

And fairly closely related to that and probably fairly close to that in time as well was then test-driven development. So, the idea that I could express design aspirations, I could express APIs, I could express unwritten code as yet unwritten code in the form of model clients, in the form of these little tests, and that I could get this lovely sense of continual assurance, if you like, of writing a bit of code and then implementing the thing to make that code true and then running it again and seeing it pass. And it was just joyful. And these two things to me brought code alive in a way that is hard to articulate. But it makes you and the code much – you’re much more connected to the code. Around this time, Java is emerging and Java becomes certainly the context in which TDD really took off. 

So, TDD started in the Smalltalk community. And Kent wrote, a tool called SUnit, which is a Smalltalk unit-testing framework. And then famously, he was on a flight with ErikGamma. And they were going to a conference. They were going to talk about how this TDD unit testing thing worked. And Erik wanted to learn what TDD was about. And Kent wanted to learn Java. And so, they sat next to each other on a flight and wrote JUnit, which is arguably one of the most productive flights in history. And that was where the first JUnit came from, was a port of SUnit into Java. And so now, it’s a numbers game. There are way, way more Java programmers than Smalltalk programmers. And TDD massively took off in the Java community, as did refactoring. Because one of the things that happens when you’re writing small bits of when you’re doing micro-design is that you rename things a lot because your understanding of them evolves. 

So, as we’re writing tests we realize that it’s not really a customer, it’s an account holder. And there’s lots of other things that a customer has, but in our context, really what we care about is the fact that they hold an account. And so, we want to call them account holder, but now we need to go back and rename all the places we were talking about them as customer and making them an account holder. And that’s pretty important. And so, the tooling starts to catch up. And that’s pretty cool, because in order to rename customer to account holder in Java, it’s actually quite a lot of manual labor. You’ve got to rename a file. If you name a package, you’ve got to move files around in directories and recreate arbitrarily deep directory hierarchies, because in Java the class name is tightly coupled to the filename and the package name is tightly coupled to the directory name. 

And so, what happened now was we started moving files around a lot and renaming files. And tools like CVS couldn’t keep up, because as soon as you rename a file in CVS, it loses history. And that was bad. And so then, the people who designed CVS then designed its successor, Subversion. And the main thing that Subversion had over CVS was you could rename a big bunch of things atomically and that all still made sense. And the forcing function on that, the thing that made that necessary, I would argue, was the perfect storm of TDD and refactoring in Java. And that then led to a huge amount of advance in that space. I’m kind of going off on a bunch of tangents now. 

JESSICA:  I love historical context. 

DAN:  It’s really important. So, refactoring means I’m moving files around. TDD is like, I don’t know. It’s like suddenly having a vocabulary around design in the small. Design in the large, you still need to do. You still need to sit back and think about what shape things are going to be when they grow up. TDD is very much about articulating the requirement in the small, articulating design in the small. And particularly then, and again this is why XP is so powerful, is all these practices are complementary. Because when you’re also pair-programming, the code example that you’re writing, the model client that you’re writing to express the API becomes a conversation piece to the pair. So, we say, “I know. We could write it like this.” And you say, “Yes, Dan. But you’re an idiot. Because what you’re asking the user to do, the programmer to do, who’s going to use this, is to remember those three things in that order. And how often are you going to do that?” 

The example I use is a database connection, because they’re always fun. So, I’m going to do a query. So, I need to connect to a database. I need to run the query. I need to close the connection. So, we’re going to have a little API that’s like connect, query, and close. And okay, great. So now, let’s write a thing for that. Okay, so what about if it blows up? Oh, okay. Try connect, query, finally close. Yeah, okay. How many people are going to remember to put that try/finally in there? Let’s go with none. What if we pushed all of that behind the API and we just had a single method query? And that means now that the querier, the database querier is responsible for making the connection and doing all the housekeeping and all that kind of thing. Yeah, okay. So, we push some complexity into the component itself but we made the API easier. Okay. That’s a design trade-off. So, now we need to talk about the design trade-off. Maybe we could cache some of those connections. Now we’re talking about connection pooling. 

So, just the decision to take away that try/finally got us into architecture conversations, infrastructure conversations, deployment conversations, availability, resilience. Because we didn’t want to keep typing those three lines of code. And this is the power of design at that kind of scale. And my mind went *exploding sound*. I just completely – it causes you to rethink design. 

And so at this point, I was with ThoughtWorks. I’d been there about a year or so. And one of the things they were doing was going into clients and typically what they call co-sourced delivery. So, a bunch of ThoughtWorks people would sit with a bunch of client people and build system. And so, part of my job as well as building systems was teaching people these new tricks. And we would get horrendously tied in knots, me trying to explain TDD to people. Because, and again, this is like 15 years ago. Programmers write programs. Coders write code. Testers test. That’s how the work breaks out. Programmers program, testers test. And programmers are sitting there going, “You want me to what now? You want me to write tests? We have cheap people down the hall that do that.” It’s that culture of like, testing is what you do until your technical chops are good enough to do programming, or something. And the flip-side of course is the testers are saying, “No, no. You can’t let the programmers write tests. They’re useless. They don’t understand testing. It’s only us testers that are keeping everything from going belly up.” And of course, we were trying ourselves in knots. 

And the point I was trying to get across to them was, “This isn’t testing. This is design.” This is a vehicle by which we can confidently make small-scale design decisions. It’s really exciting. So, I didn’t use the word ‘test’ in that description. And so, I started trying to explain TDD without using the word ‘test’, which is why it’s called behavior-driven development, because that doesn’t have the word test in it. And so, I didn’t call them tests. Because they’re not really tests, because you can’t test something that doesn’t exist. They are code examples. They become tests. I can repurpose them as tests once I’ve got something I can run them against. But where they’re most useful is while I’m designing the thing that doesn’t exist yet. But that’s not a test. That’s a specification.

JESSICA:  Interesting. 

DAN:  And so, I said: Really, what we’re doing is we’re – and I think Gojko Adzic made the term famous – specification by example. So, there’s lots of ways to specify. I could specify by algorithm. I could specify exhaustively. In this case, I specify by example. I write a model client for a thing that doesn’t exist yet. And we discuss the pros and cons of that model client. And that gives us our interface. That gives us our API. And based on that, we work backwards from the API, work from outside in. And then we implement the thing that makes the API true. And then we move on. 

Now arguably, as soon as we hit that point, that example has served its purpose. It’s like having a spec, a paragraph on a spec, and I could just put a red pen through it. Yep, we’ve got that. What’s the next one? The next one is when the customer has two addresses and we have to choose which address to send the statement to. Oh yeah, okay. So, we’re going to have a primary address, right. So, we don’t currently have a primary address. What’s the API? Let’s write some code as though we did. What would that code look like? Okay, now let’s give them a primary address. Yeah, check. We’ve got primary address. What’s the next thing? 

And so, all the way through, these are specifications. The fact that they happen to be executable and I can repurpose them to use them like I might use a test is a massive red herring. And the reason it’s a massive red herring – this isn’t just a semantic thing – code examples in general make pretty rubbish tests. 

So for instance, let me give you an example. Let’s say you and I are designing something and it’s going to do some calculation. It’s going to do some currency calculation. And we probably do the obvious case where it takes a hundred dollars and converts it into euros. And then we start thinking about edge cases. What does it do with zero? What does it do with very small amounts? What does it do with very large amounts? What does it do with an invalid currency? A currency code that doesn’t exist in the lookup table. What does it do with two valid currencies but where there isn’t a conversion rate? So we need to go and look that up. Then we start looking at edge cases. And this is all great. And we might exhaustively come up with a dozen of those. 

Now, I know you, Jess. You’re a programmer. And you’re the kind of programmer that would go and do this. You would go and then look up property-based testing. You’d look up quick check testing. You would take some of those examples, you would bake some of those examples into a set of precondition/postcondition invariant type properties, and you would use that to run a hundred million other examples against that code. And a bunch of them will blow up, because edge cases. Right? That’s testing. The thing you’re doing is testing. The thing I’m doing is specifying. And I could use that specification as the basis for writing some really good tests, for sure. But there’s a gap in what we do. We believe as programmers that we’ve got testing covered because we did TDD. And we don’t. 

JESSICA:  Yup. So, one thing I’ve observed about TDD is that when you start out with the tests, and you aim for writing tests first, then obliquely you accomplish better design. You accomplish better readability of the code because people can look at the tests to find out how to use it, hypothetically. And so, I think you’re saying split those. Optimize the code that you write initially to be really clear specifications. And if you want tests, there are different ways of optimizing tests for testing versus tests for specifying. 

DAN:  Yes, except I wouldn’t have used the word test in the second part of that. Other than that, I completely agree with you. You’re exactly on the money. So, there’s two parts to this. One is – you said two significant things and I want to tease them apart because they’re both really worth calling out. One is that when you take this approach of doing small-scale iterative emergent design, you end up generally with more testable code. That’s been my experience. You end up with smaller, more intention-revealing components. You end up with better seams. You end up with cleaner naming, more consistent naming. And I’m sure all of this is related, maybe because you keep going back over the code again and again and again because you’re kind of molding it like clay. You notice when a name – it’s more obviously jarring when names are inconsistent. You tend to spot that stuff as you go. So, as you look at the codebase over time, it tends to be more consistent, more testable, more cleanly architected. And I think there is a tendency for testability and clean architecture to be reasonably aligned. So, if I choose that I want to test this thing, it’s easier. 

The other thing you said is that the things you’re writing are serving multiple purposes. I see three purposes. The primary purpose they have was to give me confidence that I was building the right thing. Okay? So, that’s the specification piece. The second purpose they can serve is documentation. So, someone comes along later and says, “Oh, what does this do? Let’s take a look at the little executable specifications that led to this code and they will give us a clue as to what this thing was designed to do.” And the third thing is like, assurance. If I keep running these things, and they keep on working, the chances are it still does what it meant to do. So, I would argue that the primary purpose of those little code examples, which is to act as the scaffolding, the guide rails, the mold into which I’m going to pour this code and build this system – that’s its primary purpose. 

Now, to go back to our example, let’s say that you and I were writing our currency converter and we’ve come up with, I don’t know, a dozen code examples that helps us flush out really what we’re trying to say. We might find there’s a diminishing return reading those. We might find that you can really get the hang of what this thing’s supposed to do by reading probably the first two. And then the rest of it is edge cases we thought up. So, that’s great. Let’s just keep the first two. Maybe add a little bit of top and tail to them to make it really obvious what this thing does. That’s now the documentation. That’s pretty good documentation. You don’t need to read the other, whatever it was, 10. The diminishing return there is you’ll just get annoyed with the repetition. Likewise, that 12, if the purpose of testing is to give me confidence, or rather give someone who isn’t me confidence that this thing works, then if I’m a compliance officer 12 is probably 400 too few. If I’m a security tester, they don’t even scratch the surface. If I’m looking at operability and resilience and scaling and all of those things, there’s nothing here useful to me. 

JESSICA:  So, if you keep them and pretend that this is testing, you’re giving yourself a false sense of security, in some sense. 

DAN:  Boom. That’s exactly what you’re doing. And I think there is a huge hole in agile delivery. There basically is a big hole in the middle with a label called ‘testing’ hanging off it. So, we think we’ve got testing down.

JESSICA:  Because we call them tests.

DAN:  Yeah. We’ve become rubbish at it. One of the things I’ve discovered, and again this is completely by accident, when I started talking about behavior-driven development and code examples and specification by example and scenarios and given-when-then and all of that stuff, and didn’t use the word test to mean all of those things, I suddenly discovered how important testing is. Because now, guess what? It could pop back in as testing and I’m like, “Whoa. We’re not doing any of this.” And you talk to career testers and there’s a whole bunch of testers out there that are quite completely, [56:35], quite angry about things. Because they feel they’ve been completely usurped. 

And so, if you look at the world of agile testing, it tends to split the world into two things: into things we can automate and things that are manual. So, we’ve got automated testing and we’ve got manual testing. Now, that is very much a programmer’s eye view of the testing landscape. Because from a programmer’s perspective it’s things I could do in code and things I can’t do in code. From a tester’s perspective, that’s one of the least useful axes you could possibly have. And unfortunately, we’ve built an entire industry now around those two things.

JESSICA:  What would testers see? 

DAN:  Testers would see stakeholders. Testers would say, “Who am I doing this for? What evidence do I need to provide to these people, to these various stakeholders, that this thing is safe?” So they would say, from a compliance perspective, how can I evidence that this code you’re about to put live won’t get the bank shut down? From a safety perspective, how can I tell that this health monitoring system isn’t going to kill someone? From a security perspective, how can I tell that the paywall we’re about to put up isn’t going to be exploited by a cross-site scripting attack? But we don’t have any “tests” for that, because that’s not what you and I were thinking about when we were designing it. That’s not what Jamey and I were thinking about when we were putting the website together. We were thinking about, did we get the right shade of blue off the copy book?

JAMEY:  That makes sense to me. Jess mentioned earlier that my company recently started using BDD. And the reason that we did that is because I work in the agriculture industry. And so, we were finding that people on the product team like developers and programmers and the like were having a really hard time understanding why we were building things that we were building because we’d never worked on a farm. And we didn’t have a good grasp of what people who work on a farm actually need and is useful to them in their daily lives, which is the point of our product. And so, it’s interesting to me that you've been talking about it so much in the context of testing or not testing and how we test, when that’s not really that context that we were thinking about when we adopted it. And I’m wondering what you think about that and what you have to say maybe about this idea of customer empathy. 

DAN:  It’s interesting. I have been talking a lot on the technical side. I suspect that’s a function of spending time on a call with Jess. Because we don’t get to hang out very often and she’s one of my favorite programmers. So, I tend to end up in a very technical headspace when we hang out. So, I apologize for that. The point of building software, and I did sort of mention this when I was talking about value streams earlier on – the point of doing any endeavor in a work context is about meeting some customer need. Now, if that customer is a farmer – and you know, I love that your domain is agriculture. It’s completely – I’m in London. We have pictures of agriculture. 

JAMEY:  I’m sure you have greenhouses in London. I’m positive of it. 

DAN:  Okay, true story. I moved house about a year and a half ago. I moved into this house and it has a lovely big garden, lovely big yard. And it had a greenhouse in it. And it was quite a fancy greenhouse with like glass window things at the top that open and close with the temperature and all this. And we looked at this greenhouse and we looked at each other and we went, “Yeah, right.” And we sold the greenhouse on eBay. We dismantled it. Someone came and collected it. And now we have a slightly bigger patio – is my relationship with gardening. 

JAMEY:  That story makes me sad because it’s something I would want. But I’m sure somebody bought it for me off eBay who really wanted it. So, it has a happy ending.

DAN:  He was so stoked. He was so excited. He was like, “Ah, it’s perfect.” It was exactly the greenhouse he was looking for. So, it’s definitely gone to a good home. But no, so you’ve hit exactly the nail on the head, I think. Programming is programming. The value of it is the impact it has when you apply it. Code is code is code. And I had this conversation in banks. If you’re in a bank and you think that you’re moving data from system A to system B, you’re missing the point. What you're doing is enabling a German housewife to withdraw money from an ATM. You’re enabling a student to apply for a loan. You’re helping the mechanics of finance to operate in the world. It just looks like when you’re up close and staring at it that you’re moving data from system A to system B. 

So, TDD has this in spades and was one of the things I was really trying to draw out when I started describing it as behavior-driven development, is a direct relationship with the business value it was trying to deliver. And this is a common misconception with TDD and BDD, is that TDD is the stuff that happens in the code and BDD is the stuff that happens with the customer. They both do both. So, TDD in the Kent Beck sense, if you like, in the original sense, in the XP sense, is from the very outside of the application interacting with a human being or with another system or whatever it needs to do, right down into objects interacting with objects or functions interacting with functions or whatever your language affordances happen to be, and every layer in between. 

And there’s a wonderful book called ‘Growing Object-Oriented Software’ and the subtitle is ‘Guided by Tests’. And ‘guided by’ makes me happy and ‘tests’ makes me sad. The reason for this is if I could change anything about behavior-driven development, I would say that the word ‘driven’ is wrong. And I think the word ‘driven’ in test-driven development is wrong as well. Behavior isn’t what drives the development. A business need, some customer need, is what drives the development. The reason I’m doing it is that what guides the thing I build, that’s the examples. So BDD, if I got another crack at it, I’d call it example-guided development. That’s what makes it different to other styles of development, is that you use examples to guide it. And TDD is example-guided development. I’ve called it programming by example before. And one of the most powerful aspect to… 

JESSICA:  Did you just call both BDD and TDD example-guided development? 

DAN:  Yes. Because they’re the same. Or at least because they started in the same place. So TDD, if you think about the articulation of TDD, the teaching of TDD tends to be by programmers for programmers, in teams of programmers. But I’m using programmers in an XP sense where these are all the roles. We just happen to call them programmers. So, a programmer in a team may be doing some testing. They may be doing some analysis. They may be doing some operations. It doesn’t matter. So, in that context then, TDD is example-guided development. So, all of this starts at the outside. So, I describe BDD as outside-in, in contrast to top-down or bottom-up. So, top-down is this kind of reductive approach where we start with a big problem and we believe it’s made up of smaller problems and we keep on reducing those problems until we can do something. Bottom-up is where we start with little pieces and gradually assemble those pieces into bigger pieces. And eventually, we end up with a system. 

Outside-in says we understand the need we’re meeting, or at least we start with the need we’re meeting, and we work inwards from that until we have enough system to meet that need. And then we stop. And so, what you have is you start with – the onion analogy – you start with the outermost layer of the onion and you work inwards until there isn’t any more inwards, until all the pieces connect. And in fact, I was having a conversation with someone yesterday about the difference between business impact and business value. And he got me thinking. So, what we’re trying to do when we build software is create business impact. And we have a hypothesis, a bet, that that business impact will generate value. 

So, here is an example. It may be that there’s some process in an organization and that process has a lot of failures in it. We’ve identified that if we write some software or if we clean up some data or if we do some stuff, we can reduce the number of failures. So, it’s a metric. We can say, right now the number of failures is this many per day. And it costs us to resolve this. It costs us in terms of people, in terms of time, in terms of reputational risk, all of those things. Now, what we can’t do is write software to save that money. We can write software to reduce those errors. And the bet is that by reducing those errors, we’ll need fewer people or we get less reputational damage, and whatever it might be. 

JESSICA:  At the end of the show, we like to do reflections. My reflection is about when we switch from cost accounting to throughput accounting, when we switch from ‘some of you generate revenue and some of you just need to be less expensive’, and we align ourselves around a holistic goal of meeting a customer need, this is a lot more congressive way to work. And Dan, have you heard the words congressive/ingressive?

DAN:  No, I was about to ask you what congressive… 

JESSICA:  Okay. So, these words were made by Eugenia Chang. And she was on our podcast a while back and it’s everybody’s favorite episode. And congressive and ingressive, she and one of her linguist friends came up with these to replace many of the common usages of feminine and masculine. Congressive describes people or activities that work toward a common goal. That we want to accomplish something together. And ingressive is about “I want to accomplish something,” about elevating the self. And both are useful. You need ingressive activities for risk-taking and trying stuff. But in our world, in our culture, we reward a lot of ingressive behavior but we benefit more from more congressive behavior than is currently encouraged. And you can just plug these in for masculine and feminine in a lot of cases and it makes the sentences more meaningful. And when we work together to meet a goal, we’re being congressive, as opposed to what we talked about with the empire building in a cost accounting is ingressive. It’s about me. I need to meet my goals as opposed to we need to meet our goals. Yeah, so that seems like really constructive. And it all comes down to ‘The Goal’, the book, and flow and we’re all in this to create something together. Like you said, driven by a customer need. 

DAN:  Yes, yes. I completely agree with that. I agree. I haven’t heard those terms before. What I see is not just organizations but teams. So, it is kind of fractal. Start working in this way. I find there’s a self-selecting element to it. That the kinds of people who like to [inaudible] with other people tend to thrive in this context. And also, you see that collaborative behavior emerge from people where maybe you weren’t seeing it before. So, it’s almost like they had the potential to collaborate but that behavior was never rewarded or encouraged. Collaboration is necessarily the way you get work done, then you find that it does tend to draw out that more sharing and inclusive part of people’s character. 

JESSICA:  You find what you look for. 

JAMEY:  I’m thinking about a really small thing that got mentioned kind of casually near the beginning, way back when we were talking about sharing privilege. Dan started to use the word responsibility and then replaced it with duty of care. And I really, really liked that because I do think about things in terms of responsibility a lot of times. But I feel like there’s this implication then that this thing is a burden. And it’s a burden that I have to do because of these reasons. And I like duty of care instead of that, because it still has the same kind of “This is something that I have to do,” but it feels to me more like, “This is something that I have to do for my community.” Like, “It’s my job because I have these privileges and it’s important to me to raise everyone up.” It’s just interesting and it really got me thinking in the beginning of the show about what words we use and how we choose those words and why we choose those words and how different words have different connotations, even if they mean almost the same thing. Which is something that we continue to get into with the rest of the show, too. And that was really interesting for me and I really liked that. I like what you said about opportunity, too. 

JESSICA:  Yeah. Duty of care emphasizes our opportunity to help more than the word responsibility. 

JAMEY:  Yeah, I really like that. We want to do good and we want to help. And here’s a way that we can do it. Rather than here’s a burden that we have to take on. 

JESSICA:  Privilege is not a punishment. It’s not like something we’re doing wrong. It’s an opportunity.

JAMEY:  But we have to take that opportunity and actually do something with it. 

JESSICA:  And that’s the duty of care bit.

JAMEY:  Yeah. 

JESSICA:  Dan, it was lovely having you today. Thank you so much. All those stories were super interesting context and I have a bunch of things written down to think about and tweet.

DAN:  It was lovely being a guest on your podcast. Thanks very much for having me.