ºÚÁÏÃÅ

Full transcript

Ìý

Ìý

Mike Mason: Hello, and welcome to the ºÚÁÏÃÅ Technology Podcast. I'm one of your hosts, Mike Mason, and I'm joined today by Neal Ford, my co-host, as well as Kief Morris and Birgitta Böckeler. We're going to be discussing sensible defaults today. Before we do that, let's talk to our guests and just get a little bit of info about them. Kief, would you like to start, what you do for ºÚÁÏÃÅ briefly?

Ìý

Kief Morris: Sure. Kief Morris, I'm based out of London. One of the hats that I wear is the global lead for the infrastructure practice, so infrastructure engineering and that kind of thing.

Ìý

Mike: Birgitta?

Ìý

Birgitta Böckeler: Yes. I'm Birgitta Böckeler, I am a technical principal out of the ºÚÁÏÃÅ Berlin Germany office. One of the hats or many hats that I wear is what Kief is for, infrastructure practice or infrastructure community globally. I am the lead for our global software development community of practice.

Ìý

Mike: Excellent. Neal, what are talking about today?

Ìý

Neal Ford: This is a phrase that has come into usage around ºÚÁÏÃÅ, this idea of sensible defaults for projects, and the first thing we wanted to distinguish is, from the generally disliked industry term of a best practice in software development, which used to be a thing you aspired to and then quickly became an anti-pattern you try to avoid because the implication of a best practice is something where you can turn your brain off and not really engage it in making a decision.

Ìý

When some situation comes up, the best practice is, "Oh, we always do this." The term "always" and "never", those absolutes get you in trouble in nuanced ecosystems where you have to do trade-off analysis when these decisions come up. When we talk about sensible defaults, we are not talking about best practices, and we're not talking about a synonym of best practices, we're talking about something else. Let's find out from our guests exactly what we mean when we talk about sensible defaults and some of the scope of what we're talking about.

Ìý

Kief: For me, rather than best practices, what I like, I like the idea of patterns and the way we talk about patterns, and obviously, there's design patterns from architecture. I like that kind of language because it presumes that part of the definition is, well, one of the situations where this is useful or one of the situations where it's not useful, I think for any kind of practice, you need to take that into account of thinking about, there are times when this is a right thing to do and there are times then it's not the right thing to do, and just say, "Don't shut your brain off. Think about it and do what's right."

Ìý

Mike: Well, let's help the listeners a little bit. What kinds of things do we mean when we say sensible defaults? What is a sensible default?

Ìý

Birgitta: Yes, I think one thing that's also important and that I always keep trying to change the language around in ºÚÁÏÃÅ where we use this term is to say sensible default practices and not just sensible default because at least for me as a German native speaker, default is an adjective, although I recently had a discussion with somebody who said, "Yes, it was originally meant as a noun, a default," but it's really about practices because you can have sensible defaults principles, you can have sensible defaults technologies, but we are using it mostly for sensible default practices.

Ìý

For us, it's basically a starting point. As we're growing, we're now more than 10,000 people, so we want to have a starting point for people, but then also have a way to let circumstances and context, and it depends, have these as a starting point but then people can see in their contexts and their circumstances if it really makes sense or not. Many of our default practices that we have set for ourselves in ºÚÁÏÃÅ are actually rooted in extreme programming, so it's things like continuous integration, pair programming, then there's things like fast automated build, so it's really just like a minute or so when you build things locally maximum, automated pipelines, stuff like that. Maybe you have some more examples, Kief, from the infrastructure space.

Ìý

Kief: I think for the infrastructure because we talk about infrastructure as code, there's probably one thing to say as a baseline which means that the software development sensible default practices are ones that we believe in for infrastructure, things like test-driven development and continuous integration and those kinds of things. Then some of the more specific infrastructure-based ones we have are, define everything as code from the start, and we mean this as opposed to, "Let's start building stuff. Then afterward, we'll go and write some infrastructure code to try to capture it." We like to start using code as a starting point so that we're always using code.

Ìý

There's things about using pipelines, testing to deliver changes to our infrastructure code, giving teams ownership. Some of the practices are a little bit more your ways of working. The team should have ownership of the infrastructure that they need, they should have enough ownership, that kind of self-service idea there, and quality as a first-class concern for all coding, including infrastructure code, including tooling code, and build scripts and things like that, all of it, you need to really think about-- quality needs to be a part of that, rather than something that's reserved for the real code.

Ìý

Birgitta: I think the important thing is, is that it's concrete things, concrete practices that people can use as a starting point because there are a lot more generic things that apply to a lot more situations like principles or values; values like simplicity, repeatability, fast feedback, right? Then because they're still quite abstract, especially if you have maybe people in the organization or in a team that don't have as much experience yet, they don't know yet how to bring that to life. They need a starting point. That's what those default practices are supposed to be.

Ìý

Mike: When we declare something to be a sensible default practice, what does that mean? What are the implications of that? Is it just something that people can look at, and say, "Oh, yes, okay, I can see where I should start"? Tell me about what that really means.

Ìý

Kief: I think our kind of lens on it is given, say, a new project, or working with a new client, these are the things that we would expect the team to start with the saying, like, "We assume we should try to work in these ways and use these practices because we think they're generally effective," to start from there. It might be that there are reasons for a particular situation where a particular practice might not be the right thing to do, but we start with the assumption that is probably right. Let's then discuss if we think this is an exception, why we think it's an exception.

Ìý

Neal: Well, that gets to your distinction about a pattern because one of the important things about patterns is they work within a context, and it comes attached with the context. It is not just a universal thing that always applies.

Ìý

Birgitta: It's a really good-- Mike, your question, what then does it mean when we write these down? What does it mean for people on teams? Just recently, there was also a discussion on chat again, or I often hear from people that they say, "Oh, it feels like this is mandated. This is like a mandate. We have to do this, right?" Or it's being-- to use some stronger language, "has been shoved down our throats," right? That's actually exactly not the intention.

Ìý

That's why this term was chosen like sensible default. It's the default, and then you go from there. As so many other things, this can take a life of its own. [chuckles] When you have a larger-- people maybe interpret words differently, we're an international organization, with people with different language skills, and all of that. It's really important to always continue having this conversation and making sure that everybody understands that this is the default, and there are, of course, always reasons why you might want to deviate from that based on your circumstances. We still believe that these are very sensible things that really make a lot of sense, points to start with based on our collective experience in the industry.

Ìý

Kief: I think one of the interesting things about what we've chosen and the way we chose the sensible default practices within our community, Birgitta and I are coming from the software development and the infrastructure, we also have these in other areas like design, project management, and these kinds of things. With all the practices we've selected, one of the lenses we put on it is that they shouldn't be obvious things that like everybody would say, "Oh, yes, of course. Write good code," or something like that. They have to be things that the ones that we picked are ones that can sometimes be a bit controversial, especially when we go into clients. You look at pair programming, not everybody does pair programming.

Ìý

We for a reason selected to call this out and say, "Look, this isn't something that everybody necessarily does or everybody necessarily understands the value of." I think that's another key thing. When it comes to, yes, it might not always be the right thing to do, I think from a ºÚÁÏÃÅ point of view, we've chosen things that we tend to find over time, we believe are effective, we've tended to find them effective.

Ìý

Also, it's the idea that if you're going to decide not to do it on a project, it should come from a position of knowledge and understanding. You'll find that a lot of times when you come in and say, "Hey, listen, we think we should do test-driven development," and people will say, "Well, I think it's a waste of time. I don't think it's a good way to do it." If that's coming from-- not to be harsh, but it could be from a point place of ignorance, of not having experienced it and seeing how it works, and often a lot of these practices, there are myths that go around where people don't necessarily have the right idea.

Ìý

I think one of the important things that we want to have with these is that, again, we're saying they should be defaults and that if you vary from them, you should be able to vary from them, but it should come from a position of knowledge and experience and an understanding of why this case really is different as opposed to, "I'm not comfortable with that practice. I'm not really sure about doing it, so I'd rather not."

Ìý

Birgitta: It's like finding this balance between being dogmatic and being pragmatic. I mean pragmatic in a bit of a negative sense, the balance between dogmatic and pragmatic because I think sometimes when something is hard to do, then sometimes people dilute it down and then say, "Oh, we're being pragmatic about it. We're doing pragmatic TDD or pragmatic pairing or something." I think whenever we use that word, we have to be really careful and really examine why we're saying it, if it's the good kind of pragmatism, or if it's because it's hard, so we're just doing it in a pragmatic way. It's a dangerous word sometimes.

Ìý

Mike: I think the other thing. coming from a place of knowledge of having actually done the practice well, rather than just having thought you've done the practice, and if we ignore practices for a minute and then go to architecture, I think there's a lot of organizations who think they're doing microservices right now but are probably getting into sticky situations by doing it badly; doesn't necessarily mean that microservices architecture is a bad idea. It could just mean that you haven't understood it properly and haven't done it very well, and the same thing with TDD. TDD pairing, iterative delivery, I think all of those things could be done badly.

Ìý

Kief: It's hard stuff, yes, and uncomfortable. I remember the first time I tried to do unit tests and doing TDD, it was on an existing code base. It just didn't work. I couldn't get it to work and I was like, "Oh, this is stupid. I'm not going to do this."

Ìý

Mike: Sorry to sound like a guest here, but part of the thing with TDD is if it's hard to do TDD, that actually means the design of your system is hard to test, and a more easily testable system actually tends to be architected better and be more loosely coupled, all those kinds of good things. There is actually interplay between some of these sensible default practices and the actual goodness of the systems that you build. I think a lot of people don't realize that.

Ìý

Birgitta: Another thing that goes back to this, that some of these things are hard, is maybe-- there are also discussions, and I think we haven't quite resolved those, should the default practices-- should they come from a place of like, "This is our aspiration, the highest aspiration that we can have"? I think a great example of that is that at the moment, we actually have on that list continuous deployment as the default practice, as opposed to continuous delivery.

Ìý

Continuous delivery in the sense of you're always ready to deploy, but you might not always immediately do it, but every commit is ready to go, and continuous deployment as in automatically every commit goes directly to production, which is you could argue the most extreme form of this. That is our default practice at the moment. A lot of people are saying, "Oh, that's not so realistic. It's probably just a small percentage of teams," even though I think it's more than a lot of people think.

Ìý

I think we have quite a lot of clients and teams who do this, but then there's a discussion, should they be the aspirational starting point? Then you have gradual stages, the next stage if you can't do continuous deployment because your safety net is not good enough or something or your business case is too critical or something, then the next stage is continuous delivery. Yes. I don't know what you think about that, Kief.

Ìý

Neal: I think that gets to the context part because if you're in a highly regulated industry, you may not be able to do continuous deployment. There may be external constraints that prevent you from doing some of the more aspirational things that we might consider a sensible default. I think the context is important to go along anytime you talk about one of these, much like patterns.

Ìý

Kief: Yes. I do think it is-- that's a question. I don't have a firm-- in my own head because whether or not continuous delivery or continuous deployment ought to be the thing as a sensible default because most of the clients I've worked with probably have done continuous delivery rather than deployment. They've had that need to have that human-- somebody have a look at things and at least click a button before it goes on to production, and not every commit necessarily goes to production. One of the things I think about is, and I've heard this about the Tech Radar, that at one point, one of the things that people would say about the things that would maybe go into the-- I guess it was in the Adopt ring, it was like, "What can you justify? You're down the pub or what have you, can you justify to the gag, 'We're not doing this sensible default practice.'"? That's where the context thing comes in. It's like, "Well, yes, we're not doing it because we're in a regulated environment which requires two people to sign off on things or whatever it may be." To me, that would pass the test. I'd be like, "Yes, okay. That's all right. I won't laugh at you."

Ìý

Neal: Well, Kief brings up a really interesting point here about many people think that the ºÚÁÏÃÅ Technology Radar is our public pronouncement about sensible defaults for things, particularly things in our Adopt ring. In fact, I think this is an example of evolution, like the dorsal fin on a shark and the same sort of thing on a dolphin, that they're not anywhere close to being the same species, but they evolved the same feature because, at one point, the group that puts together the Technology Radar also took a stab at creating a list of sensible defaults to differentiate it from the Technology Radar, but we quickly discovered, I think, what you have is that putting technologies on there is pointless because they age worse than yogurt in sunlight, but practices are things that have some enduring stickiness on something like that.

Ìý

I think we gave up that effort, and Mike may be able to correct me because it got into a very lengthy discussion about infinite regress, how granular do you get in these things, how opinionated are you, and some of the things you're fighting with. I think it ran out of steam because of that if I remember correctly.

Ìý

Mike: The ºÚÁÏÃÅ Technology Radar has a lot of JavaScript frameworks on it, and trying to keep up with those, it's just a bit of a fool's errand. All of them-

Ìý

Birgitta: The Technology Radar has a quadrant called Techniques, and you could argue that the things that are in the techniques quadrant in the Adopt ring that at the time that we put them in the Adopt ring, they would have been a default practice in the context that they are for, right?

Ìý

Mike: I think so. Actually, what came out of that effort at looking at the Radar and saying, "Hey, what on the Radar is useful advice, a long-term useful advice, rather than just for that edition of the Radar?" we did this for the 10th anniversary of the Radar, a year or so ago, it turned out to be the techniques were the things, techniques, practices, were the things that were worth talking about in the long-term on the Radar. We did a piece called Enduring techniques from 10 years at the Radar. I think that there is a fair amount of overlap between those enduring techniques and sensible default practices.

Ìý

Kief: I guess one of the things, I see the Radar as a catalog, again, that those patterns have different things that you could do. In the techniques session, I expected there are things that there's too many things in there, even in the Adopt ring of techniques, that you should-- so it'd do all of those things. Whereas the sensible defaults is like a set that go together. They're not so much overlapping or contradicting practices that we have in there. It's a set of things that work well together.

Ìý

You look at TDD, test-driven development, continuous integration, continuous delivery, and pipelines, all of those, trunk-based development, those things work well together. In some cases, it's hard to do one of those practices without doing some of the other ones because they are complementary. I guess that's one of the things with sensible default practices. This is a set of things that is a cohesive, opinionated set of things that we think tend to work well together.

Ìý

Birgitta: You cannot do continuous delivery if you don't have a good test safety net, which you usually get when you do TDD, or it's hard to do trunk-based development or real continuous integration where you really integrate into a main branch every day if you don't have the tests, or if you do not do pair programming. They actually have to go together.

Ìý

Neal: The timing of these, I think, is interesting, because at some point, if it truly is a sensible default, it just sinks into the background noise because would you consider to used version control a sensible default now? Because how many teams don't use version control? It's just a natural assumed part of the environment now. I don't think that would be on your list. How far down do you go in terms of standard practices?

Ìý

Kief: Joel Spolsky had a listing, like, when you're going to interview as a developer with an employer, here are the things you should ask them, and if they're not doing these things, then think twice. One of them was version control. Back then, which was the early 2000s, I think, that was a valid question to ask because you would go to places where they're-- "They don't use version control."

Ìý

Mike: I even remember a version of that question being, "What version control do you use?" Walking out the door, if they gave an answer that you were supposedly not-- [laughter] that was not cool.

Ìý

Birgitta: Yes. I also sometimes say that about architecture principles, another form of-- when you want to do some lightweight governance and give some guidance to teams to make decisions, and you set up some principles. In theory, again, you can go out into the world, read all the books, and all the block posts, and get all the best or good practices out there and turn them into your organizational principles, and you will have a list of 50 of them.

Ìý

I always think of them like, set up five or six principles, which are your focus areas, almost like a strategy, and then maybe if one of them-- let's say, one of your principles is around autonomous teams or something because you really want to work on that. At some point, it's business as usual, maybe take it off the list because you don't have to explicitly mention it anymore.

Ìý

I think in our default practices as well, there are some that are really worth having on it. It's really good because it triggers conversations and discussions all the time so that we can cont continuously align an organization that's growing all the time. Some of them are maybe hardly ever talked about. Yes, maybe at some point, we can consider maybe taking them off because they're not that controversial. Maybe it's the background noise, like Neal said.

Ìý

Kief: I'm going to grab the host reigns from here. I have a question that I'm pondering, interested in what the rest of y'all think. Our sensible default practices, they're not a ºÚÁÏÃÅ thing. They're not unique to ºÚÁÏÃÅ, but it's like we see ourselves different in that, pair programming, for instance, TDD, and all those kinds of things, we really believe that you should be doing those on projects. They're not necessarily industry norms.

Ìý

There are a lot of companies that do quite well in software development that don't do pair programming. I guess what's the kind of-- sometimes a question of like, "Well, why do we insist on this?" If companies can do well without pair programming, why do we insist that we really think we ought to be doing it? Not that one in particular, but I guess this goes along with that question of like-- I can't remember how it was put earlier in the conversation, but kind of like, "Is there an arrogance here where we think we're right? Are we being dogmatic?" I guess that was the term. Is it right for us to be dogmatic and say, "Not pair programming, got to do it"?

Ìý

Neal: I think a lot of the advocacy from ºÚÁÏÃÅ, particularly around pair programming, come from people who have done it in anger and achieved very good results from it because if you really embrace the idea of pair programming and set your ego aside, it's amazing how much you can get done because coding in isolation, it's hard to be objective about what you're doing, but if you have an opinionated peer there who has no trouble at all being objective about what you're doing, then the sum of that work, there are a lot of side effects. You stay concentrated much more because you're constantly working with somebody, especially if you're doing the complementary practices, like Kief was talking about before, like ping-pong pair programming, where you're constantly swapping back and forth in a really nice cadence.

Ìý

I think it's one of those things that, experience is the only thing that really tells you if you have the right personality type, and the right temperament to be a good peer programmer. The people that I find advocate for it the most are the ones who've done it a lot and find that it amplifies their ability to program above what they can achieve as an individual.

Ìý

Mike: I think if you have a software organization that has a whole bunch of 10X programmers on it, and that's working for you with all of that siloed knowledge and giant egos and stuff like that, okay, fine. I believe you can be successful with that, but the problem that we always have is we operate in the real world where not everybody is actually that smart. We'd much rather talk about a 10X team than 10X individuals.

Ìý

We care a lot about what happens when somebody leaves the building. If you have a whole bunch of siloed knowledge and someone leaves, then that's a problem. I think, to us, the things that we would advocate for as those sensible defaults are actually the much more inclusive version of software engineering, that I personally think is much more sustainable long term and much better for organizations.

Ìý

Birgitta: Although there are also some people, especially with pair programming, who argue that for some people it's not as inclusive, but then there's also ways to do it differently or do it pragmatically [laughs] according to the context, but I think what you said about the 10X engineers versus team efficiency, maybe without getting too much into why pair programming specifically is so big for us, I think one thing that we keep trying to fight for and it always feels a little bit like fighting against the stream is this idea of team efficiency over individual efficiency.

Ìý

A lot of us developers also, we really like just writing our stuff, being really fast, especially once we're experienced, it's just such a rush to get something done really quickly and everything. That's why a lot of people in this job I think optimize for their individual efficiency which overall doesn't improve your delivery as an organization, as a team. A lot of these practices help improve team efficiency, but it's harder to do for the individuals. It's this constant swimming against the stream, it feels, to try and put that at the front.

Ìý

Neal: That's a good entrée for the question. Did you want to say something about that, Kief, before--

Ìý

Kief: Yes. I wanted to follow up on that because one criticism that I've heard about these or some of our practices when we come into-- Part of my thinking of why we do this, we're a consultancy, we go into an organization, we work with other developers there, and I do think part of the reason that people bring us in is because they hope that we have good practice and can help them to learn to do things more effectively or learn new things.

Ìý

The 10X thing is interesting, the 10X developer thing because I've had criticism from people who say, "These things are great for Thoughtworkers because you're all elite programmers who've been specially selected, but they're not practical for regular developers. Our developers can't do this stuff, these practices that you're trying to force down our throats," whereas I think actually in my experiences, these things help developers get better. I think that's part of the thing that we have to get across sometimes.

Ìý

Birgitta: Is it a correlation or is it causation?

Ìý

Neal: Well, that's an equally good segue to my next question, which is, can you describe in the Venn diagram the overlap between sensible defaults and paved roads, where those concepts overlap and where they diverge from each other? Because it's a lot of talk about paved roads, building infrastructure that makes it super easy for teams, don't mandate that they use them, but make it so that they have easy infrastructure on demand, et cetera. How does that differ from this idea of sensible defaults if it does?

Ìý

Birgitta: You mean a paved road also being something like an actual platform or like software and tools that you can use that make it easier for you as a developer to do the right thing, that's what you mean by paved road, yes? I think that is maybe an analog. You can't just throw a list of default practices out there and describe them in one paragraph and then, "Everybody, go do this."

Ìý

If some of them are important to you as an organization and you want them to be easy, you want to make it easy to do the right thing, then you also have to provide the support. I think that also for some of the harder or more controversial practices is where also, in our organization, in ºÚÁÏÃÅ, we need to get better in some of those areas as well because for some of the practices, it feels like people are rediscovering them again and again, which is fine because you have to learn them by doing them and through a process, but I feel like we could have a bit more support also in terms of materials and not just saying, "Here's a one-paragraph description. [chuckles] Go out and do it."

Ìý

Kief: I think going back to something we were saying earlier about these practices being difficult to do and often needing to be complementary, we talked about the trunk-based development and TDD and CI, and all those things that really reinforce each other, I think there is also-- the infrastructure has to be there to make that easy to do, and not just infrastructure, it's the skill--

Ìý

One example is feature toggles. In order to do trunk-based development, one of the obstacles, and to move away from, say, doing branching and feature branching and those kinds of things is, well, how do you have work in progress that isn't ready to go to production, but is in the code base on main and could end up in production? Feature toggle is one of the techniques to use for that, but then that requires having, "Okay, are we going to use a framework for that? How do we build them? How do we manage them? How do we keep them from proliferating and having hundreds and thousands of feature toggles that are no longer relevant?"

Ìý

That's just one example. There's loads of little things where it's like you need to have those pieces in place and you need to have people used to using those and able to help each other and help new joiners to the team. Definitely need to have the paved roads in terms of the tooling and platform and infrastructure, and also in terms of just the teams and the ways of working that people are comfortable working with those.

Ìý

Birgitta: Oh, yes. I was thinking more in our context as a consultancy company, where you cannot have these tools because you go to different clients, but of course, in a digital product organization, you would use default practices then, of course. It's a very good point. You need to have those things in place to make it the tools and all of that to make it easy for people to do, or like pairing, remote pairing tooling, and stuff like that.

Ìý

Kief: For us, it's knowing what some of those tools are. One of those things we get in our internal lists and chat rooms is like, "Oh, I started on this new with a new team. We're trying to introduce this practice. What's a good tool to use?" I think for us it's like having, "Okay, what tools work well, what don't necessarily work well," and to get into my own area of infrastructure, one of those struggles we've had with infrastructure with some of the things that we've picked as sensible defaults, like test-driven development and continuous integration and all the software development practices, is there's not great tooling out there for that. It's really hard because the tooling isn't quite there which is a struggle. That's an industry-level lack of paved road for some of these practices, I think, a sidebar.

Ìý

Birgitta: That reminds me of another podcast episode in the ºÚÁÏÃÅ Technology Podcast, a few episodes ago, I just listened to it on an evening walk. When you talk to Guo Xiao, our CEO, who started as a developer at ºÚÁÏÃÅ in 1999, and he's talking about how his first project was-- the first project that ºÚÁÏÃÅ ever tried extreme programming out of desperation, as he said, [chuckles] I think, and the amount of times in that podcast episode, you all use the sentence, "Well, we didn't have X then yet, there was no continuous integration server." I think you were wondering if there was even JUnit at the time. There it was also about figuring out the tooling, so you could even do those things.

Ìý

Neal: What's the best granularity of a sensible default? Is this an individual person on a project? Is this at the team level? Is this an organizational level? Is it industry-wide? Where's the right level of granularity for this I guess?

Ìý

Kief: I guess it's got to be team level, right?. It's going to be whoever you're working with and collaborating with. I think, Mike, you were saying earlier about how these-- they tend to be inclusive. They tend to be bringing people in. So, at least the team level, I would say, and if your team is working closely with other teams, it's very hard if you're doing continuous delivery and pipelines and all that stuff, and somebody else is in a very maybe waterfall way of working, doing integration testing and that kind of an environment is difficult. That's my thoughts anyways.

Ìý

Birgitta: Yes. Team level. Then maybe on an organizational level, you have a set that a team would pull and then say, "These are our defaults," because another way to think about it is also that you have a default on the team, but then you do it like 80% of the time. Say, you switch it around, like you say, "Not-- Okay, there's always one person assigned to a story. Then we always have discussion if we have two people pairing on a story," but you switch it around to the default of having always two people pair and you have a discussion whenever you want to have an exception or whenever you want to do code review instead of care programming and so on. You maybe don't do it 100% of the time, goes back to dogmatic, but you only have the discussion when you do not want to do it.

Ìý

Neal: I think that's an important distinction to be made between the idea of a sensible default versus a lot of governance activities because a sensible default is very much a proactive activity. At the beginning of a process, what default should I pick? Whereas a lot of governance activities are reactive in terms of policing things that fall outside the bounds of what you're trying to do. I think proactivity is an interesting feature of providing guidance rather than a restriction on teams and what they want to do and what their starting point is for trying to solve a particular problem.

Ìý

Birgitta: Although you should, of course, also be reactive. Always retrospect on how they're going and maybe discover new defaults on the way or discover that one of them doesn't work.

Ìý

Neal: Yes. I don't think it's a substitute for governance, but I think it's A good-- it's more of a gentler way to do governance of saying--

Ìý

Birgitta: It's a puzzle piece of governance.

Ìý

Neal: Exactly.

Ìý

Kief: I think the best thing with these is where you view these not as things that somebody's telling you you have to do, but this is useful for us to do. It should be useful for you as a team to adopt these practices. If you're finding they're not useful, then you need to question that. It might be the practice. It might be that you need help using the practice. You should be viewing it as, and Birgitta, I think you said the very beginning about some people will worry about, is this something we're mandated to use? It's like, we don't have people going around to ºÚÁÏÃÅ projects and saying, "Are you doing TDD, and why not? Are you doing it good enough? Are you following--" It's not like that.

Ìý

Birgitta: We are actually. [chuckles] We are actually though. We're going around, we're sending out surveys, asking people, "Are you applying this, partially applying this," all of that, but it's always super important to put it in the context of, "This is a survey to gather information and data also about how useful this actually is. You will not be on a status dashboard as red if you haven't done any of these."

Ìý

Kief: If we see a lot of people aren't using some particular practices, we'll be really curious, "Oh, what's going on there? Is it not working out for you, or is there something we should-"

Ìý

Birgitta: Exactly.

Ìý

Kief: -know about? Should we take it off the list?"

Ìý

Neal: Do you have some good guidelines for when you override the default? Because it is default practices. When does the default get overridden? Certainly, it's case by case, but are there any general guidelines?

Ìý

Mike: Kief had a sensible default for infrastructure earlier, which is that teams should own their infrastructure or control their infrastructure. I bet you a million pounds most teams do not control their own infrastructure at the moment. I don't know what happens when you run into that, Kief.

Ìý

Kief: Yes, and even that, so there's nuance to that one. It's less about the idea that, well, a developer should completely own their infrastructure top to bottom, own it in the sense of being responsible for everything to do with it. It's not that. It's more that you should have the control that you need, which starts getting a bit fuzzy, but it's like you should be able to-- you shouldn't be sitting around waiting not able to do something because you don't have whatever level of control you need, but how you decide--

Ìý

There was something we said earlier, I think, about-- I've got a blank on it now. [chuckles] We had something earlier where we talked about-- it was the knowledge thing of-- I think having those kinds of retrospective type things where you talk about things and what's holding us back, what's helping us and reflecting on the practices that you're doing and the way that you're working is really important.

Ìý

I do think it's important if you're deciding, "Maybe this practice isn't right for us," that again, you do it from that place of knowledge. That might mean, can you bring in somebody who knows more about this and has had more experience with it and can maybe help with some of the things that we're getting stuck with because maybe-- or are there ways of working around things that can-- some of these governance examples where people say, "We're in a highly regulated industry. Therefore, we can't do agile. We can't do all this kind of stuff." It's like, well, no, actually you can, if you know how.

Ìý

I think it's that bringing in the knowledge, I think it's important to go through at least that step of-- given that we've said we really think these are things that you should consider as defaults, go through some kind of due diligence, I guess, [chuckles] before you-- I think that's one thing I would say as a--

Ìý

Birgitta: Then when you deviate, I think then it's always-- again, we don't want to do the practices for the practices' sake, but there's ultimate goals that we have behind them. I talked about those values before like fast feedback and stuff like that. We want that so that we can just be really good at delivering software and also delivering the right software.

Ìý

Then when we deviate, it becomes all about monitoring what happens there. It's also important to have people on the team who have the experience, who understand why we're doing them, and how they connect to each other. The defaults are really useful, especially I think also for more junior people who are on this Dreyfus learning model more in the beginning, who are like, "Yes, this is something to start with," and I just do it by the book. Then you also need at least one or two people on the team who really understand why and know when to break the rules.

Ìý

Neal: All right. Well, that's a great overview of this idea of sensible default practices here at ºÚÁÏÃÅ. Any last comments you want to make to leave our audience with about this idea?

Ìý

Mike: Do let us know if you tried it and if it was useful. We always look out for comments on the podcast episodes, and actually haven't said this yet, but if you're listening to us, please give us a rating and a thumbs up or whatever because that helps other people find the podcast, but if you find the concept interesting, have a go and let us know.

Ìý

Neal: Yes, and thank you very much to Kief and Birgitta for joining us today. You've obviously thought quite a lot about this, and it was terrific to get your insights into this.

Ìý

Birgitta: Yes, thanks for having us.

Ìý

Kief: Thanks, it was a good talk.

Ìý

Neal: Thanks, everyone, and we will see you on the next episode of the ºÚÁÏÃÅ Technology Podcast. Have a great day.