When should we create an ADR for certain types of decisions? Right. That's probably the number one mistake I've seen new people who are new to ADRs make is a lot of times ago from no documentation practice, like nothing. 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 ring on new technical debt? Is this a decision that we can change our minds easily later? If it's something that's like easy to change later, maybe
“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:
_____
Our Sponsors
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.
Skills Matter is the global community and events platform for software professionals. 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.
Like this episode?
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Pledge your support by becoming a patron.
For episode show notes, visit techleadjournal.dev/episodes/113.
