#113 - Architecture Decision Record (ADR) - Michael Keeling

 

   

“An ADR is a simple text file describing the context, the decision, and the consequences of a single architectural decision stored in the version control repository."

Michael Keeling is an experienced software engineer, architect, and the author of “Design It!: From Programmer to Software Architect”. In this episode, Michael shared in-depth about ADR. He first shared his story of discovering ADR before describing what an ADR is. Michael then shared the objectives and benefits of using ADR to record architecture decisions and explained the key behavior changes happening when we practise ADR. Towards the end, Michael shared a few practical tips on creating and updating ADR, some patterns and anti-patterns he observed from his experience, and suggestions on how we can practise ADR effectively as a team.  

Listen out for:

  • Career Journey - [00:05:02]
  • Discovering ADR - [00:07:05]
  • ADR - [00:08:57]
  • ADR Objectives - [00:11:18]
  • Facilitating Good Design - [00:12:31]
  • Not Capturing Design Decisions - [00:15:06]
  • Distance Between Developers and Design - [00:17:19]
  • Key Behaviour Changes - [00:19:11]
  • Recent Popularity - [00:22:11]
  • ADR Tips - [00:24:31]
  • When to Create an ADR - [00:26:36]
  • Updating Previous ADR - [00:27:55]
  • Diagrams - [00:29:28]
  • ADR Patterns - [00:31:06]
  • ADR Anti-Patterns - [00:32:48]
  • Doing ADR as a Team - [00:34:25]
  • 3 Tech Lead Wisdom - [00:37:05]

_____

Michael Keeling’s Bio
Michael Keeling is a software engineer at Kiavi and the author of Design It!: From Programmer to Software Architect. Prior to Kiavi, he worked at IBM on the Watson Discovery Service and has experience with a variety of software systems including service-oriented architectures, enterprise search systems, and even combat systems. Michael is an award-winning speaker and regularly participates in the architecture and agile communities. He holds a Masters in Software Engineering from Carnegie Mellon University and a BS in Computer Science from the College of William and Mary. His current research interests include software design methods, patterns, and human factors of software engineering.

Follow Michael:

Mentions & Links:

 

Our Sponsor - Founders Wellbeing
Mental well-being is a silent pandemic. According to the WHO, depression and anxiety cost the global economy over USD 1 trillion every year. It’s time to make a difference!
Learn how to enhance your lives through a master class on mental wellness. Visit founderswellbeing.com/masterclass and enter TLJ20 for a 20% discount.
Our Sponsor - DevTernity 2022
DevTernity 2022 (devternity.com) is the top international software development conference with an emphasis on coding, architecture, and tech leadership skills. The lineup is truly stellar and features many legends of software development like Robert "Uncle Bob" Martin, Kent Beck, Scott Hanselman, Venkat Subramaniam, Kevlin Henney, Allen Holub, Sandro Mancuso, and many others!
The conference takes place online, and we have the 10% discount code for you: AWSM_TLJ.
Our Sponsor - Skills Matter
Today’s episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals.
Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones.
Head on over to skillsmatter.com to become part of the tech community that matters most to you - it’s free to join and easy to keep up with the latest tech trends.
Our Sponsor - Tech Lead Journal Shop
Are you looking for a new cool swag?

Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available.

Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags.

 

Like this episode?
Follow @techleadjournal on LinkedIn, Twitter, Instagram.
Buy me a coffee or become a patron.

 

Quotes

Discovering ADR

  • Everything is moving really quickly, and we were struggling with some of the basic knowledge sharing, basic design principles, things like that, that I think a lot of teams struggle with. But with us being fairly young and then really in a bit of a pressure grinder. There was a lot of pressure to deliver and move quickly at the time.

  • Michael Nygard wrote this blog post that kind of described this experience report, this idea that he was playing with, which was: What if we write down a single decision, a single architectural decision? It’s just a simple markdown, very simple kind of text file. What if we keep the format very straightforward in the style of a pattern?

  • If we describe the context of the world, the forces that are at play—maybe they’re business forces or technical, they could be political—these are the things that are kind of acting on our decision. What it is that we’re going to do. And then, as a result of applying this decision, describe the consequences. There could be trade-offs. There could be quality attributes promoted. It could be new risks or benefit.

  • That’s an ADR, really, in a nutshell, kind of in its essence. A really simple text file describes the context, the decision, and the consequences of that decision.

ADR

  • The thing that was really different—cause design decisions, architecture decisions they’ve been around for probably five, six years at least—the thing that was different, though, was keep it simple and then put it in the version control repository.

ADR Objectives

  • ADRs are great for capturing those decisions. And yeah, you’re right. It’s one decision at a time, which is really amazing and powerful. Because one decision is easy, and then you just do that every day, and then you look back and next thing you know, you’ve got 30-40 pages of documentation of all these great design discussions that have happened over the past however many months. And that’s great, like capturing these design discussions and kind of describing the rationale for the design is really important.

  • But what I really like about ADRs and the thing that I think is actually even more important is how it facilitates that discussion about design, and it really puts design kind of at the forefront, front and center.

  • Recording the decisions is great, but the fact that you’re coming together as a team and talking about them and really focusing on that is even better. To me, I think that’s even more important perhaps than the decision itself.

Facilitating Good Design

  • A lot of times, a lot of teams get into this unfortunate state where architecture is done by somebody else. Somebody else, somewhere in the organization. You know, the so-called ivory tower architect. ADRs, it brings things that are very distant—architecture is somebody else’s problem—it helps bring it closer to home.

  • That’s important for a number of reasons. A big one being that it’s empowering. The fact that these ADRs are close to the code. They’re simple text files that it’s the team who’s supposed to be writing them and owning them. Suddenly, you’re giving agency to the team to own their own architecture and to be responsible for it.

  • This is important because it’s easy to make mistakes with architecture. You might have a perfect design, something that’s implementing exactly the architecture that you want. Someone completely unaware could unravel that entire architecture.

  • Probably the biggest thing with all that is being empowered, you’re able to move quicker. You’re able to be more nimble. A little bit more agile. So you’re not waiting for other people to make decisions and tell you what to do.

Not Capturing Design Decisions

  • With architecture, you can find structure in the code. You can see it. Sometimes you can recreate it. You can kind of make a reasonable sketch based on what you see in the code. But recreating what people were thinking at the time that they made those decisions is kind of impossible.

  • You’re in the middle of a field and there’s a fence in the middle of the field and you need to remove this fence. You want to remove it, but it’s here. Somebody put it here for a reason. So, you kind of have to make a call. Was this thing here for a reason? Can you remove the fence? Or maybe it’s not there for a reason at all, and it’s perfectly okay to delete.

  • For teams who haven’t reported design rationale, who haven’t kind of written down really any documentation at all, that’s what we end up seeing a lot of. You can recreate the structure. You can see the fence. But you have no idea why it’s there. How is it safe to change? Whether it’s okay to delete or not?

Distance Between Developers and Design

  • When the distance between developers and design is too big, for example, you have like a separate document not in the source control, developers perceive design as having little value.

  • When architecture is maintained in other documents, or, you know, in a different knowledge repository of some kind, it kind of goes out of sight and out of mind. At least in my experience, it becomes a template that you just have to fill in because there’s a policy that says you have to fill it in. Not necessarily something that you really care about or try to take ownership over.

  • Bringing the ADRs in to the version control repository, it creates this association. Things that are close together, if you value one of those things, and if you can associate other things to the thing that you value, then you’ll end up liking all of those things that are kind of associated with it.

  • For developers, if you highly value the code, and if the code is the number one most important thing, we put the code in version control. That’s where all the important stuff goes. Let’s put the ADRs in version control. It’s like, okay, well, since it’s in version control, then it must also be important too.

  • We’ve kind of created this association between design and code that at least gets the foot in the door. It gets the conversation started about the importance of design. Any developers who are skeptics—architecture, somebody else’s problem, not my problem—bringing it in closer helps to at least kind of show that there is value here.

Key Behaviour Changes

  • One of the first important things is building up social proof. If you’re trying to bring ADRs into your team, the most important person is not you. It’s actually the next person. If you’re the only person writing ADRs, nobody’s really gonna pay much attention. But as soon as a second person starts contributing, that’s got power. So now, it’s not just one person. We’ve got a group that’s starting to form. So now, you’ve got a lot of people who are saying ADRs are important. Design is important.

  • The next thing is the fact that these ADRs are written down, and the way we phrase them is important too. You write it down. You have other people on your team review it through your pull request process, maybe. That is, in a way, forming a written commitment. It’s like a promise. We made a decision. We will do this thing that we’ve decided. Because it’s written down, it starts to form this bond, almost. Like your word is your bond. You said we’re going to do this thing, and now you want to be consistent with the promise you made, which is another one of these psychological principles, the consistency principle.

  • What that ends up doing is teams feel more compelled, almost, to follow through on the designs that they’re creating. So we’ve made a decision. We’ve written it down. Everybody’s read it. We told everybody we’re doing this. Now, we’re actually going to do it. All this kind of leads to building up more and more support for this idea that, hey, we’re the kind of team who thinks about design. We’re the kind of team who writes down decisions before we make them. Kind of the self-identity, almost, of the individuals on the team start to change.

Recent Popularity

  • There were kind of two branches from that point. One was the architecture community. They went very deep in views and view models. So there are a lot of people proposing decision in viewpoints things like that. Really powerful techniques, but also, you have to know a lot. You have to have tooling. Fairly heavyweight to use.

  • Nygard was kind of coming from the agile patterns of tradition. His approach that he pitched out there, very lightweight, text based, no barrier to entry. You just get started using it.

  • From my own experiences using it, because there are a few kinds of guide rails to it, it takes a little bit of time to figure out how exactly it works. Those changing behaviors, you’re looking at six months to two years.

  • It’s kind of a journey for introducing the ADRs, learning how to use them well, developing the skills, coaching. All that kind of stuff to develop a team who is able to do these things.

ADR Tips

  • What’s the most ADRs I’ve ever seen? So I’ve written a ton of ADRs, but I think in any particular software system, the most I’ve ever seen is maybe in the 30 to 40 range. So that’s a solid year and a half of folks diligently recording decisions, and that’s a lot. I think that’s the most I’ve ever seen.

  • Architectural decisions aren’t made every day. Becoming aware of when you’re making an architectural decision is probably the most important thing getting started.

  • One thing I’ve seen recently happening as my teams have been getting more sophisticated or more aware in thinking about design is we started to look at other techniques to kind of blend with ADRs. My IBM teams were doing architectural hoisting. So they would not only write the ADR, but they would then introduce a framework to enforce certain decisions that were made or to enforce certain quality attributes that were desirable.

  • There was a really great framework that my team was talking about just today called ArchUnit. It was kind of a JUnit testing for architecture. So, taking something like that and combining it with ADRs is like a powerful combo.

When to Create an ADR

  • Probably the number one mistake I’ve seen new people who are new to ADRs make is, a lot of times you go from no documentation practice, like nothing, and then, “Oh my gosh. ADR is amazing”. And then everything is an ADR.

  • On my team, we’ve got a heuristic. Does this decision deal with one of our most important quality attributes? Does this decision bring on new technical debt? Does this decision materially change the structure in some way? Is this a decision that we can change our minds easily later? If it’s something that’s easy to change later, maybe it’s not so architectural.

Updating Previous ADR

  • The idea behind the append only kind of decision log, it’s about helping you to think about and helping you to capture that history. So, you don’t want to go back and say like, “Oh well, we changed our mind, so let’s just delete this old one and change it.”

  • Keep the old one. What you want to do is write a new decision, and then update the old one to point to the new one. Even like take a cross reference, they can reference back and forth.

  • One of the things my teams are doing recently is adding a new section to the bottom of the decision record for reflection. We go back and just kind of how did it work out? Did we actually get the consequences that we thought we were going to get? If you could go back in time and do something different, would you have still made the same decision? They put it down on the bottom of the file. Just add it to the end of it as some additional reflection.

  • Fix the typos. It’s okay. Nobody wants the spelling errors and things, but don’t completely rewrite the thing.

Diagrams

  • Diagrams are great. ADR is all about effective communication. So anything that’s going to help you communicate effectively, go ahead and put in that ADR. There’s no hard and fast rule that says it has to be a text only.

  • In a way, the decision log itself is like a change over time view of the architecture.

  • Another thing that we’ve had some interesting success with is remixing. So create a new document. Maybe it’s your security view of the system or your availability view of the software. You might add a couple of new diagrams, describe a few structures in that, and then point to the most important ADRs that are related to that particular quality attribute that you’re trying to describe.

ADR Patterns

  • One of the patterns that I tend to encourage is really anything to get things started. So, introducing stub ADRs. ADRs, they’re lightweight, but sometimes in the heat of the moment, it’s just a little bit too much work, even for something so short as an ADR. But if you at least capture the stub, just like a very brief, what’s the decision? And as many notes as you can about the rationale. It’s at least a start.

  • I really love to use ADRs as a teaching tool, a way for a kind of coaching.

  • One of my favorite things with that is delegating to people or asking for volunteers. Especially folks who maybe have never written one before. And then letting them do their best. Just letting them give it a try and then sitting down and pairing with them afterwards to kind of talk about, ask some questions or dig into the consequences.

  • Referencing ADRs from the code. So that’s probably like the best sign of when a team has kind of made it. When you’ve kind of crossed that chasm. When you see comments in the code that are then referencing ADRs that have been written, so you have this kind of nice cross reference. You can see the structure in the code, and then people are linking out to other documentation to help describe the rationale.

  • And, of course, it’s all in the version control repository. So, you know, when they copy it down, you’ll be able to find it. It’s all there.

ADR Anti-Patterns

  • “Everything is an ADR”. I’ve seen that happen on every single team. Probably another one. “Everything is not an ADR”.

  • For new folks, especially, something that I see is, we’ll just call it maybe simple consequences. You’ll have this great decision. You’ll have a pretty good context, and then you’ll see like one consequence and it’ll be like, “Because we thought it was good.” That’s not a consequence.

  • One of the things I strongly encourage is digging for those consequences. So go for at least three. Go for more than three. And nearly always when that happens, when you really think about it, you’re like stumped. It’s like what could possibly happen? What trade offs could there possibly be?

  • And then all of a sudden, ideas will flow, and you’ll come up with five or six more consequences and they’re going to be the most interesting things that maybe you wouldn’t have otherwise thought of. This is where maybe you’ll consider new technical risks, new engineering risks introduced by the change, or particular quality attributes promoted that maybe weren’t at the top of mind at that moment.

  • Too few consequences, I think, is a pretty common anti pattern.

Doing ADR as a Team

  • One of my favorites is a lot of times, I’ll see a team together in a whiteboard jam. Everybody kind of at the whiteboard talking about different things. Everybody’s throwing up different ideas. They’re asking questions, taking turns with the marker, either physically or metaphorically, if we’re all remote. Taking turns telling stories back and forth and walking through our diagrams. When that happens, sometimes but not always, someone will start taking notes to the side about things that folks are talking about.

  • These are the starts of the ADRs. In a whiteboard jam, like you’re just going through probably three, four alternatives, different ways of structuring things and really walking through hard parts of the architecture. It helps to talk that through. To have somebody to explain it to you and to ask questions. But then, even better is when you have another person to record what you’re saying. Because sometimes you’re just not going to remember these brilliant moments that you’re having.

  • I’ve seen that phenomenon also happen during like mob programming. So when you’ve got like a whole group of people together working on the same code at the same time. The same kind of phenomenon happens. Somebody will be making design decisions without even realizing it, and then another teammate will just kind of notice and jot down the notes. You know, kind of create almost a proto ADR.

  • A shared Google Document. People jotting down context and trying to get the context laid out. Talking about what are the consequences? Brainstorming consequences in real time.

  • The most important thing though, you still have to have somebody go through the final document and phrase the ADR to share back to the group. Even with a group effort, you still have to have one person, maybe two in a pair to go through and actually write it up.

3 Tech Lead Wisdom

  1. Get it working, then get it working better.

    • When do I tell myself this? Anytime I’m facing a really difficult problem. Maybe I don’t know how to get started. Maybe it’s intimidating in some way.

    • First thing. Let’s just get it working, get something working. And once that something is working, then we can get it working better.

  2. Remember, you’re not alone.

    • We’re all in this together. We’re a great team. You can work together even on really hard problems. And design is hard. Architecture is hard.

    • So, just remembering that you’re not alone is really important. Ask for help, ask questions, and people will help and the end result will be awesome.

  3. Be excellent to each other.

    • Design is hard. Architecture is hard. You’re putting yourself out there. You’re asking for feedback a lot on these things. Just be kind to one another. Be excellent to each other. Help each other learn is such a huge thing.
Transcript

[00:01:38] Episode Introduction

Henry Suryawirawan: Hello again, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your podcast app and on LinkedIn, Twitter, and Instagram. And if you’d like to support my journey creating this podcast, please subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Michael Keeling. Michael is an experienced software engineer, software architect, and the author of “Design It!”. In this episode, Michael shared in-depth about architecture decision record, also widely known as ADR. He first shared his story of discovering ADR before describing what an ADR is. Michael then shared the objectives and benefits of using ADR to record architecture decisions and explained the key behavior changes we can observe when we practice ADR. Towards the end, Michael shared a few practical tips on creating and updating ADR, some patterns and anti-patterns he observed from his experience, and suggestions on how we can practice ADR effectively as a team.

I really enjoyed my conversation with Michael, learning in-depth about ADR and some practical tips we can use to practice it more effectively. And if you also find this episode useful, please help share it with your friends and colleagues who can also benefit from listening to this episode. I always appreciate your support in sharing and spreading this podcast and the knowledge to more people. Let’s jump to my conversation with Michael after hearing some words from our sponsors.

[00:04:34] Introduction

Henry Suryawirawan: Hey everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me someone named Michael Keeling. He’s actually one of the thought leaders in the tech industry. He has written a number of books including “Design It!”. Today, we’ll be talking a topic, which I’m very interested in, which is architectural decision records, or some people know as ADR. So Michael, today I’m very, very pleased to have you in the show. So looking forward for this conversation.

Michael Keeling: Awesome. Yeah. Thanks for having me.

[00:05:02] Career Journey

Henry Suryawirawan: Michael, I always like to start my conversation by asking my guests to share more about themselves. Maybe telling the highlights or turning points in your career.

Michael Keeling: Sure. Give a bit of a history. So, going way back, graduating from Carnegie Mellon with a computer science degree. Kind of a classic, I guess, computer science, math set up getting into the software industry that way. The one thing from that degree that I was in the program there, I took a software engineering class my senior year, and that was, like far and away, the most awesome class I took. Probably, the one course that stuck with me that I found myself applying after I got out into the real world.

My first job working for US Department of Defense contractor. There, I had the opportunity to work on what was called the AGES modernization project, which probably, nobody knows what I’m talking about with that. But it was probably one of the largest model driven architecture projects around, certainly at the time, which was a really cool opportunity to see these model-driven architecture and model-driven engineering practices firsthand on a real, complex distributed mission critical system. The stuff we were building was shooting missiles, things like that. So pretty intense.

So from there, went back to university for software engineering to Carnegie Mellon, which is what brought me to Pittsburgh where I am today still. At Carnegie Mellon had the opportunity to take some cool courses and meet some awesome people, including Mary Shaw and David Garland. Did some reading courses with him and did a semester or so of research with David, and that was kind of what eventually led to the book, “Design It!”. So a lot of digging into details there.

Yeah. And since then, been in Pittsburgh working for a local startup that was acquired by IBM, and then within IBM we were like re-acquired, I guess, by Watson. So, working for one of the biggest companies around, I guess, at that point. Got in pretty early, not too early, but fairly early on the microservices and cloud tech stacks. That was really an exciting time to be doing all that. Machine learning, AI, microservices. And then since then, in the past four years, I’ve been with a fintech called Kiavi. Working at a really big company is great, but I felt like it was time to get back to startups. So, that’s why I left and eventually made my way back to a small company.

[00:07:05] Discovering ADR

Henry Suryawirawan: So it’s been quite a journey. So you started from the US Department of Defense, to startups, to big corporate, IBM, and back to startup. Thanks for sharing your journey. I think it’s really interesting. So throughout your journey, I think you discovered this thing called architectural decision record, or let’s call it short, ADR. So maybe tell us more. How was the story? How did you discover it? And how you’ve been a prominent supporter of that, I guess?

Michael Keeling: Yeah. So back on my IBM team, we were a fairly small team, a fairly young team as well. So I was one of the more senior engineers on the team, but most of the seven or eight developers were right out of university. So maybe one or two years working in the professional software development. I guess, as I briefly alluded in my story at the beginning, you know, we were getting into cloud-based microservices. We were getting into AI. We were getting into cloud-based technologies, search technologies, the AI. Everything is moving really quickly and we were struggling with some of the basic knowledge sharing, basic design principles, things like that, that I think a lot of teams struggle with. But with us being fairly young and then really in a bit of a pressure grinder. There was a lot of pressure to deliver and move quickly at the time with the early days of Watson.

That’s the situation. I’m open and looking for any kind of new techniques to bring to my team for getting us to think more about architecture, think more about design. That’s when I came across this Twitter thread one day. I think it was Nat Pryce, sharing a tool that he’d written for recording this thing called the ADRs, over the command line. Just a very simple command line tool and like, “Okay, this sounds neat. What are ADRs?” I digged in, and I found all this cool stuff that sounded really great. So brought that back to my team. “Hey, found this thing called ADRs. Should we give it a try?” And, of course, my team is great. They’re like, “Yeah let’s do it. What’s an ADR?” So I had to teach them all that, and I guess learn myself cause it was my first time with that. I guess that’s the discovery. And then bringing it in to try and solve some problems.

[00:08:57] ADR

Henry Suryawirawan: So maybe in the first place, for people maybe who may not be familiar with this thing called ADR, first, maybe what is the definition of ADR? Is there a good way to summarize what is an ADR?

Michael Keeling: Yeah. So the cool thing with ADRs. The idea, the way that we practice it today, comes from this blog post by Michael Nygard. He wrote the “Release It!” book, which I always think is like the companion book to my “Design It!”. So he wrote this blog post that kind of described this experience report, this idea that he was playing with, which was okay. What if we write down a single decision, a single architectural decision? And what if we do it? Write it down. It’s just a simple markdown, very simple kind of text file. What if we keep the format very straightforward? In the style of a pattern, like a design pattern from Christopher Alexander. You know, if we describe the context of the world, the forces that are at play, maybe they’re business forces or technical, they could be political. These are the things that are kind of acting on our decision. What it is that we’re going to do? And then, as a result of applying this decision, describe the consequences. Again, very like how does the world change after we’ve done this decision? There could be trade-offs. There could be quality attributes promoted. It could be new risks or benefit. So that’s an ADR, really, in a nutshell, kind of in its essence, a really simple text file describes the context, the decision, and the consequences of that decision.

I think the real cool part, the thing that was really different, cause design decisions, architecture decisions they’ve been around for probably five, six years at least. The study of architecture decisions had been a focus in the research area for a number of years before Nygard’s blog post. The thing that was different, though, was keep it simple and then put it in the version control repository. Put it right in your Git repo next to the code. You know, those two things are really different than what anybody in the architecture community at least had been talking about up to that point. So I guess there’s the long answer of what an ADR is.

Henry Suryawirawan: As we dive deeper later on, if I can just summarize it a little bit, it is like a simple text-based decision records that you store in version control, and you kind of like capture a single decision, right? It’s not like a very overarching architecture document that could be how many hundreds of pages long. And it captures three things. Context. What is the context when you make the decision. And the decision itself. And the consequences, maybe the trade-offs and maybe the few things that you consider during the discussion and you decide and then you capture what are the consequences of the decisions.

[00:11:18] ADR Objectives

Henry Suryawirawan: So thanks for sharing this in a good way, right? In a summarized format. So people should consider ADR, but what is the true objective of it? Is it just to capture decision records for people to refer back maybe in the next few years? They forgot what they did and they just look back. Or is there any other different objectives that you think ADR could help?

Michael Keeling: ADRs are great for capturing those decisions. And yeah, you’re right. It’s one decision at a time, which is really amazing and powerful. Because one decision is easy, and then you just do that every day, and then you look back and next thing you know, you’ve got 30-40 pages of documentation of all these great design discussions that have happened over the past however many months. And that’s great, like capturing these design discussions and kind of describing the rationale for the design is really important.

But what I really like about ADRs and the thing that I think is actually even more important is how it facilitates that discussion about design, and it really puts design kind of at the forefront, front and center. So it’s kind of putting your team in this amazing place of being, I guess, where you’re talking about design, where you’re talking about architecture. That’s really where the magic starts to happen. Recording the decisions is great, but the fact that you’re coming together as a team and talking about them and really focusing on that is even better. I don’t know. That, to me, I think that’s even more important perhaps than the decision itself.

[00:12:31] Facilitating Good Design

Henry Suryawirawan: So yeah. I think you brought this good point about facilitating the design, maybe the discussion itself and the decisions. So not many engineers in the team, I think, would be involved, in traditional companies, right? They rely on architect, some architect teams or maybe some senior engineers in the team to decide for them and to come up with all these design decisions. But I think I like what you mentioned is that when you have this kind of probably cadence or maybe practice together in a software engineering team, you kind of like spread the knowledge about good design. You put it in a phrase “It makes good design inevitable in the team”.

But maybe tell us more why every software engineer needs to be strong in design and architecture? Because traditionally, again, like I said, in some companies, they rely on some senior architects or software engineers to make the decision for them.

Michael Keeling: Right. Yeah. So a lot of times, I guess, a lot of teams get into this unfortunate state where architecture is done by somebody else. Somebody else somewhere in the organization. You know, the so-called ivory tower architect. I just hate that term. So unfortunate, right? But ADRs, it brings things that are very distant. Architecture is somebody else’s problem. It helps bring it closer to home.

I think that’s important for a number of reasons. A big one being that it’s empowering. The fact that these ADRs are close to the code. They’re kind of simple text files that it’s the team who’s supposed to be writing them and owning them. Suddenly, you’re giving agency to the team to own their own architecture and to be responsible for it, which is super powerful. This is important because it’s easy to make mistakes with architecture. Especially the cloud based systems that I’ve traditionally worked on. You might have a perfect design. Something that’s implementing exactly the architecture that you want. Someone completely unaware could unravel that entire architecture.

So I’ve had cases where someone unbeknownst, unaware that perhaps there were certain like layers in the architecture. They would come in and violate those layers, and then in the process incur tremendous performance penalties that could, like, increase the cloud costs, the compute costs, things like that, or introduce instability in some way purely by accident. But, you know, bringing the ADRs close, now it’s your responsibility as a developer to kind of be aware of these things and to think a little bit more carefully about what the architecture is and to follow it.

Probably the biggest thing with all that is being empowered, you’re able to move quicker. You’re able to be more nimble. A little bit more agile. So you’re not waiting on other people to make decisions and tell you what to do. As the developer, as the architect, wearing both of those hats, all those things, you get to make the call, which helps you to, hopefully, move a little bit quicker and be a little bit more agile as a team. Which is another fantastic outcome, I think.

[00:15:06] Not Capturing Design Decisions

Henry Suryawirawan: I think there are also a couple of things, right? I know that some companies practice this ivory tower architecture and things like that, producing hundreds of pages of documents. But there are also aspects where some teams, most likely in the startups, they don’t actually capture those design decisions. So tell us more about the danger situation of doing this practice, not capturing anything down.

Michael Keeling: Yeah. So, this is a big discussion a couple of weeks ago. I was at my first in-person conference since before the pandemic, which was great. We were chatting about the importance of rationale. Like with architecture, you can find structure in the code. You can see it. Sometimes you can recreate it. You can kind of make a reasonable sketch based on what you see in the code. But recreating what people were thinking at the time that they made those decisions is kind of impossible.

I guess there’s the Chesterton’s Fence parable, which approximately goes: you’re in the middle of a field and there’s a fence in the middle of the field and you need to remove this fence. You want to remove it. But it’s here. Somebody put it here for a reason. So, you kind of have to make a call. Was this thing here for a reason? Can you remove the fence? Or maybe it’s not there for a reason at all, and it’s perfectly okay to delete. So, getting back to code, for teams who haven’t reported design rationale, who haven’t kind of written down really any documentation at all, that’s what we end up seeing a lot of, right? You can recreate the structure. You can see the fence. But you have no idea why it’s there. How is it safe to change? Whether it’s okay to delete or not? Now, we’re going through a lot of that right now. So with a startup company growing really fast, we’ve got a lot of code and not everybody is around anymore to explain exactly how the code got to be the way it is. So think there’s a finer appreciation, perhaps, of things like ADRs.

Henry Suryawirawan: So you mentioned about people leaving. The churn, the retention. In many companies, this is common, right? So people come and go, and I think the danger of not capturing the decisions like you sometimes will probably ponder why such things happen in the code? And you really can’t tell whether it’s safe to delete, it’s safe to refactor, and things like that. So maybe when we have ADRs, at least we have the context, again, coming back to the templates that you mentioned, the context. And why the decision was made? And is there any trade-offs or consequences when the decision was made at that point in time?

[00:17:19] Distance Between Developers and Design

Henry Suryawirawan: I think when I read some of your articles as well, I think that’s one thing that I also piqued interest in. So we know that ADRs, the good practice, is to capture it along with the code in the version control. In your article, you mentioned “when the distance between developers and design is too big, maybe, for example, you have like a separate document not in the source control, developers perceive design as having little value”. So tell us more why you have this observation?

Michael Keeling: Yeah. So it’s back to that idea of the, I guess, kind of the other, right? So when architecture is maintained in other documents, or, you know, in a different knowledge repository of some kind, it kind of goes out of sight and out of mind. At least in my experience, it becomes a template that you just have to fill in because there’s a policy that says you have to fill it in. Not necessarily something that you really care about or try and take ownership over.

Bringing the ADRs in to the version control repository, it creates this association. There’s this idea in psychology of an association principle. So things that are close together, if you value one of those things, and if you can associate other things to the thing that you value, then you’ll end up liking all of those things that are kind of associated with it. So this is like a common sales technique that you’ll see. People who liked this movie also liked this product. They’re trying to create that association to bring you in to get you to like this other thing. We could effectively do the same thing with design through ADRs. For developers, if you highly value the code, and if the code is the number one most important thing. Well, code is important. We put the code in version control. That’s where all the important stuff goes. “Hey, look at that. Let’s put the ADRs in version control”. It’s like, okay, well, since it’s in version control, then it must also be important too. So we’ve kind of created this association between design and code that at least gets the foot in the door. It gets the conversation started about the importance of design. So, any developers who are skeptics — architecture, somebody else’s problem, not my problem — bringing it in closer helps to at least kind of show that there is value here.

[00:19:11] Key Behaviour Changes

Henry Suryawirawan: And you captured this nicely. So things related to this practice or association technique where developers start to value architecture decisions more. And I think you observed there are four key behavior changes if we start practicing ADR more frequently as part of the team culture. Maybe can share more what are these key behavior changes that you observe?

Michael Keeling: Yeah. So once we kind of create that association and once we get developers kind of talking about design and being willing to think about architecture more and actually give this ADR a thing a try, couple of cool things start to happen.

One of the first important things is building up kind of this, I guess, almost social proof. So, the most important person writing an ADR. If you’re trying to bring ADRs into your team, the most important person is not you. It’s actually the next person. If you’re the only person writing ADRs, nobody’s really gonna pay much attention. But as soon as a second person starts contributing, that’s got power. So now it’s not just one person. We’ve got a group that’s starting to form. So now you’ve got a lot of people who are saying ADRs are important. Design is important. So that’s one kind of area. Other people writing ADRs and that starts to kind of change the behavior a little bit like, “Oh, everybody else is doing it. Maybe I should do it”.

The next thing is the fact that these ADRs are written down, and the way we phrase them is important too. When we’re saying the decision part, we’re saying we will do XYZ. We will introduce a data layer and it will be the bottom-most layer. Only the business layers are allowed to use it. Maybe that’s your decision. So, you write that up. You write it down. You have other people on your team review it through your pull request process, maybe. That is, in a way, forming a written commitment. It’s like a promise. We made a decision. We will do this thing that we’ve decided. Because it’s written down, it starts to form this bond, almost. Like your word is your bond. You said we’re going to do this thing, and now you want to be consistent with the promise you made, which is another one of these psychological principles, consistency principle.

So what that ends up doing is teams feel more compelled, almost, to follow through on the designs that they’re creating. So we’ve made a decision. We’ve written it down. Everybody’s read it. We told everybody we’re doing this. Now, we’re actually going to do it, which is pretty cool. All this kind of leads to building up more and more support, I guess, for this idea that, hey, we’re the kind of team who thinks about design. We’re the kind of team who writes down decisions before we make them. Kind of the self-identity, almost, of the individuals on the team start to change. That itself becomes almost reinforcing idea, which is very powerful. I know there’s a lot of really neat mechanisms built into this little tiny text document, which I think is really, really great.

Henry Suryawirawan: And you mentioned like, coming back to the explanation you did earlier, so the real value of ADR is not just to capture the design in that version control. But actually, you will transform the developers in the team to start thinking more about design. Maybe they will turn into architects in the team, right? So everyone will also become an architect because they’re like making the decisions together. Maybe the overarching goal is to start changing the team culture themselves to think or care more about design before they actually jump into the code and write the code.

[00:22:11] Recent Popularity

Henry Suryawirawan: I think this kind of team culture is very important because in some companies, yeah, again, it’s not visible. Everyone just does based on features, functions or pressure from the business people, stakeholders, hey, I want this feature done, but they don’t think through the design. So I think one of the area of this ADR where it can help is actually to build this team culture. Why is it only lately quite popular? Because I think Michael Nygard wrote the book quite a number of years ago. But somehow these ideas seem to pick up quite recently in many different companies. So if you can share maybe your observation, why is that so?

Michael Keeling: Yeah. I’ve been really curious about that myself. So like, why is everybody doing ADRs now? I think what it comes down to is, so maybe a year or two years before the Nygard blog post, Philippe Kruchten and a couple of co-authors, whose name I’m forgetting, wrote a kind of a challenge to the architecture community about, we’ve had like the 4+1 view, and we’ve had viewpoints, an IEEE viewpoints. All these things for a long time. It seems like decisions are becoming a thing. We need different ways of thinking about decisions and things. That kind of got a lot of people thinking about this topic of architecture decisions.

There were kind of two branches from that point. One was the architecture community. They went very deep in views and view models. So there are a lot of people proposing decision in viewpoints things like that. Really powerful techniques, but also, you have to know a lot. You have to have tooling. Fairly heavyweight to use. Nygard was kind of coming from the agile patterns tradition. His approach that he had kind of pitched out there, very lightweight, text based, no barrier to entry. You just get started using it. So I think that was kind of the invitation.

From my own experiences using it. Because there are a few kinds of guide rails to it, it takes a little bit of time to figure out how exactly it works. Those changing behaviors that we were just chatting about. On teams that I’ve worked on the past, you’re looking at six months to two years. Something like that. It’s kind of a journey for, you know, introducing the ADRs, learning how to use them well, developing the skills, coaching. All that kind of stuff to kind of develop a team who is able to do these things. I don’t know, just guessing. It seems like a bunch of teams were probably picking up these techniques in the year or two or three after Nygard’s blog post. You figure it takes a year or two to kind of get used to it, train up on it, and then from there it sort of spreads as more and more people getting proficient. So, I don’t know. One thought on it.

[00:24:31] ADR Tips

Henry Suryawirawan: Yeah. Who knows? But anyway, now it becomes like a trend in many of the tech startups or maybe big companies who value architecture decisions more, and probably, they don’t think the traditional way of documenting the architecture decisions was probably effective. Anyway, when we have these ADRs, I assume if you are a team, which has been around for many years, if you make all the small decisions in the ADRs, I guess it could be pretty long as well. It could turn out into hundreds of pages as well. So maybe any kind of tips here. Are there things that should not be in ADRs? How we should manage the ADRs better? Instead of any new developers starting from zero and read all the ADRs. It’s going to take a long time.

Michael Keeling: Yeah. Well, I guess a couple of interesting thoughts. What’s the most ADRs I’ve ever seen? So I’ve written a ton of ADRs, but I think in any particular software system, the most I’ve ever seen is maybe in the 30 to 40 range. So that’s a solid year and a half of folks diligently recording decisions, and that’s a lot. I think that’s the most I’ve ever seen. Most of the time, it’s in the dozen or so that you might see for a particular module or something that someone owns, which I guess when you like, take it all together can be a lot. I guess that’s that. Architectural decisions aren’t made every day. Becoming aware of when you’re making an architectural decision is probably the most important thing getting started.

I think one thing I’ve seen recently happening as my teams have been kind of getting more sophisticated or more aware in thinking about design is we started to look to other techniques to kind of blend with ADRs. My IBM teams were doing architectural hoisting, which is a really great technique. So they would not only write the ADR, but they would then introduce a framework to enforce certain decisions that were made or to enforce certain quality attributes that were desirable. I’ve seen a lot more design rules being implemented these days, which is really great.

There was a really great framework that my team was talking about just today called ArchUnit. It was kind of a JUnit testing for architecture. So, taking something like that and combining it with ADRs is like a powerful combo. So thinking about modularity and then blending techniques, blending ways of documenting decisions seems to be pretty powerful.

[00:26:36] When to Create an ADR

Henry Suryawirawan: You mentioned something about knowing when to create the ADRs. How do you decide what kind of scope that warrants us to create an ADR? Because some teams, I believe, if they don’t get some kind of guidelines, they’ll just probably create many or some like, they are not sure when to create, right? So maybe any kind of guidelines when should we create an ADR for certain types of decisions?

Michael Keeling: Right. That’s probably the number one mistake I’ve seen new people who are new to ADRs make is, a lot of times you go from no documentation practice, like nothing, and then, “Oh my gosh. ADR is amazing”. And then everything is an ADR, like literally anything that’s going on.

On my team, we’ve got a heuristic. We’ve got a bunch of questions that we try and get people to answer. Does this decision deal with one of our most important quality attributes? Does this decision bring on new technical debt? Does this decision materially change the structure in some way? Is this a decision that we can change our minds easily later? If it’s something that’s like easy to change later, maybe it’s not so architectural. That’s actually the first coaching point. What is architecture? What is software architecture? What does it mean to make an architectural decision? Yeah. And the ADRs just expose that immediately. You’ll see things coming in, like, “Oh, we should name all the methods with a verb”. It’s like, that’s a good design decision, but it’s not quite architectural.

[00:27:55] Updating Previous ADR

Henry Suryawirawan: Thanks for sharing some of the heuristics. I think some people will find it very useful, because sometimes it’s not easy to gauge when we should create ADRs. Especially if we are beginners. We just learn from the books. It looks cool. Others are doing it. Let’s try. But when you try it, it’s like, “Okay, when?” And I think you mentioned also another good practice in ADR is to actually do append only like in version control. Append and not modify. Is there some situation where you need to modify or delete? Or how do you actually make a retrospective decision, I guess? How do you do that?

Michael Keeling: Yeah, so the idea behind the append only kind of decision log, it’s really about helping you to think about and helping you to capture that history. So, you don’t want to go back and say like, “Oh well, we changed our mind, so let’s just delete this old one and change it. Make us look really smart.” That kind of a thing. Keep the old one. What you want to do is write a new decision, and then update the old one to kind of point to the new one. Even like take a cross reference, they can reference back and forth.

One of the thing my teams are doing recently is adding a new section to the bottom of the decision record for reflection. So, in some cases, it may have been six months or a year since we made a decision. We go back and just kind of how did it work out? Did we actually get the consequences that we thought we were going to get? If you could go back in time and do something differently, would you have still made the same decision? They put it down on the bottom of the file. Just add it to the end of it as kind of some additional reflection. People get really uptight, I guess, about “Oh, it’s append only. You know, don’t modify.” Nah. Fix the typos. It’s okay. Nobody wants the spelling errors and things, but don’t like completely rewrite the thing. That’s kind of the spirit about what we’re talking about.

[00:29:28] Diagrams

Henry Suryawirawan: Yeah. So how about diagrams? Architecture diagrams, logical diagrams, data model diagrams, and things like that. Are they also part of ADRs?

Michael Keeling: Oh yeah. Diagrams are great. ADRs is all about effective communication. So anything that’s going to help you communicate effectively, go ahead and put in that ADR. There’s no hard and fast rule that says it has to be text only. So, my teams a lot of times would keep it very lightweight. It used to be in the pre-pandemic days, you know, a picture of a whiteboard. Somebody would like sketch something up, take a picture of it, put it in the ADR. Doesn’t have to be anything fancy. Nowadays, we’ll see screen caps. A screen capture of like a Miro sketch or Mermaid. I think GitHub has added Mermaid support, so people are starting to experiment with that, which is pretty cool. Kind of having rendered class diagrams or sequence diagrams in the markdown. So that’s pretty cool. But yeah, views are fantastic. That kind of reminds me. In a way, the decision log itself is like a change over time kind of view of the architecture.

Another thing that we’ve had some interesting success with is remixing. So create a new document. Maybe it’s your security view of the system or your availability view of the software. You might add a couple of new diagrams, describe a few structures in that, and then point to the most important ADRs that are related to that particular quality attribute that you’re trying to describe. So it’s almost like a best of, if you’re interested in this one idea, this is where you go for it. Instead of only having that historical, oldest and newest kind of view of the world.

Henry Suryawirawan: Yeah. So I think that’s pretty useful, because sometimes if you just trace back, it takes too long to actually form what is the current view of the system.

Michael Keeling: Yeah. It’s interesting. Maybe not what you need right now.

[00:31:06] ADR Patterns

Henry Suryawirawan: So maybe since you have done this for many years now, I assume you have found certain patterns and anti patterns that maybe you can share. Let’s start with patterns. What are some of the good patterns that people should think about when they implement ADRs?

Michael Keeling: We’ve chatted about a couple of them already, which I think is great. One of the patterns that I tend to encourage is really anything to get things started. So, introducing stub ADRs. ADRs, they’re lightweight, but sometimes in the heat of the moment, it’s just a little bit too much work, even for something so short as an ADR. But if you at least capture the stub, just like a very brief, what’s the decision? And as many notes as you can about the rationale. It’s at least a start. So that’s a pretty good pattern, I think, that I’ve seen in a lot of places.

Another one, I think we kind of chatted about this briefly as well. I really love to use ADRs as a teaching tool, a way for kind of coaching. One of my favorite things with that is delegating to people saying like, “Hey, you write the ADR”, or asking for volunteers. Especially folks who maybe have never written one before. And then letting them do their best. Just letting them give it a try and then sitting down and pairing with them afterwards to kind of talk about, ask some questions or dig into the consequences, things like that. So that’s another, I think, pretty good pattern that I’ve seen. Really good tool for ADRs.

One more. Referencing ADRs from the code. So that’s probably like the best sign of when a team has kind of made it. When you’ve kind of crossed that chasm. When you see comments in the code that are then referencing ADRs that have been written. So you have this kind of nice cross reference, right? Like you can see the structure in the code, and then people are linking out to other documentation to help describe the rationale. That’s just huge. I really like that as a practice. And, of course, it’s all in the version control repository. So, you know, when they copy it down, you’ll be able to find it. It’s all there.

[00:32:48] ADR Anti-Patterns

Henry Suryawirawan: Yeah. I like it when you say that the sign of the teams who made it in terms of practicing ADR is actually when they’re referencing it in many parts of the code as well. So it’s not just a silo, one document that is maintained by a few people and the rest of developers just write the code, right? So I think that’s a nice way to put it. How about anti patterns? So maybe you have found some anti patterns along the way.

Michael Keeling: Yeah. So some things that maybe don’t go so well. So we chatted a little bit about everything is an ADR. I’ve seen that happen on every single team. Probably another one. Everything is not an ADR and that’s okay. For new folks, especially, something that I see is, we’ll just call it maybe simple consequences. You’ll have this great decision. You’ll have a pretty good context, and then you’ll see like one consequence and it’ll be like, “Because we thought it was good.” It’s like, “Oh my gosh.” That’s not a consequence. Or it’ll be sometimes even sillier than that. It’ll be like the code will be more maintainable or something. Okay. Well, I mean, at least there’s a quality attribute, but it’s just this one thing. So I think one of the things I really strongly encourage is digging for those consequences. So go for at least three. Go for more than three. And nearly always when that happens, when you really think about it, you’re like stumped. It’s like what could possibly happen? What trade offs could there possibly be? And then all of a sudden, the dam will break. Ideas will flow, and you’ll come up with five or six more consequences and they’re going to be the most interesting things that maybe you wouldn’t have otherwise thought of. This is where maybe you’ll consider new technical risks, new engineering risks introduced by the change, or particular quality attributes promoted that maybe weren’t at top of mind at that moment. So too few consequences, I think, is a pretty common anti pattern.

[00:34:25] Doing ADR as a Team

Henry Suryawirawan: So you mentioned about all these simple consequences and things like that. How should we, as a team, make decisions together as an ADR? I imagine, because there could be many practices, like one person delegated this, make the decisions, or is it like every time you want to make ADR, you do team huddle? Many different practices. How should we make a good decision together as a team in the form of ADR? Maybe you can also cover this one.

Michael Keeling: There’s a lot of interesting ways that I’ve seen teams do this. So one of my favorites, I think, is a lot of times, I’ll see a team together in a whiteboard jam. Everybody kind of at the whiteboard talking about different things. Everybody’s throwing up different ideas. They’re asking questions, taking turns with the marker, either physically or metaphorically, if we’re all remote. Taking turns telling stories back and forth and walking through our diagrams. When that happens, sometimes but not always, but when it does, it’s really beautiful. Someone will start taking notes to the side about things that folks are talking about. Just right there in the Miro board, for example.

These are the starts of the ADRs. In a whiteboard jam, like you’re just going through probably three, four alternatives, different ways of structuring things and really walking through hard parts of the architecture. It helps to talk that through. To have somebody to explain it to you and to ask questions. But then, even better is when you have another person to record what you’re saying. Because sometimes you’re just not going to remember these brilliant moments that you’re having. I think that’s one way I’ve seen it come together really well. I’ve seen that phenomenon also happen during like mob programming. So when you’ve got like a whole group of people together working on the same code at the same time. The same kind of phenomenon happens. Somebody will be making design decisions without even realizing it, and then another teammate will just kind of notice and jot down the notes. You know, kind of create almost a proto ADR. Ready to go.

So there’s, I guess, kind of two things. I was in a session last week that was pretty interesting. We had a big question. So somebody posed a big important question. I believe it involved a certain API technology. I think it was gRPC we were talking about, and whether or not gRPC was going to be allowed in a certain part of the architecture. Whether we would have our services offered gRPC interfaces or not in that part of the architecture. With that, it was actually a mob altogether working on just that one decision. A shared Google Document. People jotting down context and trying to get the context laid out. Talking about like what are the consequences? Brainstorming consequences in real time. That was really great. I think the most important thing though, you still have to kind of have somebody go through the final document and kind of phrase the ADR to share back to the group. Even with like a group effort, you still have to have one person, maybe two in a pair go through and actually like write it up.

Henry Suryawirawan: Yeah. Sometimes it’s tricky in the discussion who will capture that, or maybe summarize it? Because I think it takes some time as well to actually capture down the essence.

[00:37:05] 3 Tech Lead Wisdom

Henry Suryawirawan: So, Michael, it’s been a pleasure talking about these ADRs. I learned a lot. I’m sure all the listeners here will also learn from this conversation. But unfortunately, due to time, we have to wrap up pretty soon. But I have one last question. Maybe this is like sharing your own ADRs, right? So what I call three technical leadership wisdom. It’s something that I think is like an advice for listeners, maybe from your journey, from your experience, or maybe from your expertise. So what would be your three technical leadership wisdom?

Michael Keeling: So I guess folks who have worked with me for a while, my teammates, they’ll probably find this amusing. I have these catch phrases. Mantras, maybe that’s a better way to put it. Things that I tell myself. So one of those is get it working, then get it working better. When do I tell myself this? Anytime I’m facing a really difficult problem. Maybe I don’t know how to get started. Maybe it’s intimidating in some way. First thing. Let’s just get it working, get something working. And once that something is working, then we can get it working better. I don’t know, maybe it’s back to my TDD roots or something. You get something working and then get it working better. So there’s one.

Second bit of wisdom maybe is remember you’re not alone. This is, I think, something that is very thematic throughout “Design It!” is this idea that, like, we’re all in this together. We’re a great team. You can work together even on really hard problems, and design is hard. Architecture is hard. So, just remembering that you’re not alone, I think, is really important. Ask for help, ask questions, and people will help and the end result will be awesome.

Third one. Chatting with my son ahead of time about this question, and he encouraged this bit of wisdom. I think it’s great. The Bill and Ted wisdom of be excellent to each other. I think that’s just true. A hundred percent true. Design is hard. Architecture is hard. You’re putting yourself out there. You’re asking for feedback a lot on these things. Just be kind to one another. Be excellent to each other. Help each other learn is such a huge thing.

Henry Suryawirawan: I like the last one. So be excellent to each other. Sometimes we developers want to work in silo, right?

Michael Keeling: Silo, and then very grumpy about things or very afraid or something. But no, just be excellent.

Henry Suryawirawan: Yeah. If we are kind to each other, I’m sure we create a better community, better kind of results together.

Michael Keeling: 100%.

Henry Suryawirawan: We’re not alone. Yeah. We are not alone at the end of the day.

So Michael, for people who love this conversation, if they want to follow up with you, ask more questions. Is there a place for them to find you online?

Michael Keeling: Yeah. Twitter will probably be the best place to reach out to me. Probably the easiest one. My name, Michael Keeling on Twitter.

Henry Suryawirawan: Thanks for that. Again, Michael, appreciate your time today. Hope you have a very good success in promoting these ADRs to more people. I know that you are writing a lot of blogs or papers recently. Hopefully, we can share that to people as well when this episode is released. So, thanks again for that.

Michael Keeling: Yeah, excellent. Thank you very much for having me. This was great.

– End –