1 00:00:00,000 --> 00:00:03,000 Hey, a quick message, for those of you who are listening to this 2 00:00:03,000 --> 00:00:07,500 episode on Spotify, I have a small favor to ask Spotify. 3 00:00:07,500 --> 00:00:11,000 Now allows mobile users to rate podcasts, I would really 4 00:00:11,000 --> 00:00:13,300 appreciate it. If you can take a quick, pause 5 00:00:13,300 --> 00:00:16,100 to go to the technique Journal podcast page, and leave your 6 00:00:16,100 --> 00:00:18,800 favorite show. Your best rating on Spotify. 7 00:00:19,200 --> 00:00:21,800 It will help me a lot to get this podcast to reach more 8 00:00:21,800 --> 00:00:24,300 people on the platform. Thanks a lot. 9 00:00:24,800 --> 00:00:27,500 What if we write down the single decision, the single 10 00:00:27,500 --> 00:00:29,800 architectural decision, write it down the truth. 11 00:00:30,000 --> 00:00:32,800 A simple markdown, very simple kind of text file. 12 00:00:33,000 --> 00:00:36,800 What if we keep the format very straightforward in the style of 13 00:00:36,800 --> 00:00:38,500 a pattern? You know, if we describe the 14 00:00:38,500 --> 00:00:41,600 context of the world, the forces that are play, maybe their 15 00:00:41,600 --> 00:00:44,800 business courses or technical, they could be political. 16 00:00:45,100 --> 00:00:47,300 These are the things that are kind of acting on our decision, 17 00:00:47,500 --> 00:00:48,800 what it is that we're going to do. 18 00:00:49,200 --> 00:00:52,000 And then as a result of applying this decision, describe the 19 00:00:52,000 --> 00:00:54,800 consequences. So at the Navy Yard really 20 00:00:54,800 --> 00:00:57,600 intend nutshell, really simple, text file describes, the 21 00:00:57,608 --> 00:00:59,900 context, the decision, in the consequences of that decision. 22 00:01:00,000 --> 00:01:06,200 Vision. Hey everyone. 23 00:01:06,700 --> 00:01:08,600 My name is Henry Surya, we Robin. 24 00:01:10,300 --> 00:01:13,200 And you're listening to the technology, you know, podcast 25 00:01:13,500 --> 00:01:15,900 the show where I'll be bringing you the greatest technical 26 00:01:15,900 --> 00:01:19,700 leaders practitioners and thought leaders in the industry 27 00:01:20,100 --> 00:01:24,400 to discuss about their Journey ideas and practices that we all 28 00:01:24,400 --> 00:01:28,000 can learn and apply to build a highly performing technical team 29 00:01:28,500 --> 00:01:30,800 and to make an impact in your personal work. 30 00:01:31,300 --> 00:01:39,900 So, let's dive into our Journal. Hello again, my friends my list. 31 00:01:40,000 --> 00:01:43,200 - welcome to the technology. Now, podcast the show where you 32 00:01:43,208 --> 00:01:45,900 can learn about technical leadership and Excellence from 33 00:01:45,900 --> 00:01:48,300 my conversations with great thought, leaders in the tech 34 00:01:48,300 --> 00:01:50,400 industry. If this is your first time 35 00:01:50,400 --> 00:01:53,400 listening to tackle a journal, subscribe and follow the show on 36 00:01:53,400 --> 00:01:56,500 your podcast app and on LinkedIn, Twitter and Instagram. 37 00:01:56,800 --> 00:01:59,900 And if you'd like to support my journey, creating this podcast, 38 00:02:00,000 --> 00:02:02,200 Please Subscribe as a patron at technology. 39 00:02:02,200 --> 00:02:06,400 Another death / Patron. My guest for today's episode is 40 00:02:06,400 --> 00:02:09,100 Michael killing. Michael is an experienced 41 00:02:09,100 --> 00:02:11,700 software engineer. Stop by architect and the author 42 00:02:11,700 --> 00:02:15,700 of design it in this episode, Michael shared in depth about 43 00:02:15,700 --> 00:02:19,700 architecture decision record. Also widely known as a Dr. He 44 00:02:19,700 --> 00:02:22,700 first shared his story of discovering Adia before. 45 00:02:22,700 --> 00:02:26,100 Describing what inedia is Michael then, share the 46 00:02:26,100 --> 00:02:29,600 objectives and benefits of using idea to record architecture 47 00:02:29,600 --> 00:02:32,400 decisions and explain the key Behavior changes. 48 00:02:32,400 --> 00:02:36,700 We can observe when we practice ADR towards the end, Michael 49 00:02:36,700 --> 00:02:40,400 shared a few practical tips on creating and updating a They are 50 00:02:40,600 --> 00:02:44,200 some patterns and anti-patterns, he observed from his experience 51 00:02:44,500 --> 00:02:48,200 and suggestions on how we can practice Adia effectively as a 52 00:02:48,200 --> 00:02:50,700 team. I really enjoyed my conversation 53 00:02:50,700 --> 00:02:54,500 with Michael learning in depth about ADR and some practical 54 00:02:54,500 --> 00:02:57,200 tips we can use to practice it more effectively. 55 00:02:57,500 --> 00:03:00,200 And if you also find this episode useful, please help, 56 00:03:00,200 --> 00:03:03,000 share it with your friends and colleagues, who can also benefit 57 00:03:03,000 --> 00:03:06,400 from listening to this episode. I always appreciate your support 58 00:03:06,400 --> 00:03:09,200 in sharing and spreading this podcast and the knowledge to 59 00:03:09,200 --> 00:03:12,000 more people. Let's jump to my conversation 60 00:03:12,000 --> 00:03:15,100 with Michael after hearing some words from our sponsors. 61 00:03:15,300 --> 00:03:17,600 Mental well-being is a silent pandemic. 62 00:03:18,000 --> 00:03:22,000 According to who depression and anxiety caused the global 63 00:03:22,000 --> 00:03:25,700 economy over one trillion US dollars every year, it's time to 64 00:03:25,708 --> 00:03:29,000 make a difference, learn how to enhance your life through a 65 00:03:29,008 --> 00:03:30,900 master class from Founders well-being. 66 00:03:30,900 --> 00:03:34,500 And my good friend, Sandy brow on mental Wellness, visit 67 00:03:34,500 --> 00:03:39,000 Founders well-being.com / Master Class to enroll and enter tlj 68 00:03:39,100 --> 00:03:44,400 24. 20% discount be a better version of yourself and make an 69 00:03:44,400 --> 00:03:46,600 impact. Today's episode is proudly 70 00:03:46,600 --> 00:03:50,300 sponsored by skills matter. The global community and events 71 00:03:50,300 --> 00:03:52,900 platform. With more than 100,000 software 72 00:03:52,900 --> 00:03:56,600 professionals here members. Can organize their learning 73 00:03:56,600 --> 00:03:59,000 experiences around the technology topics. 74 00:03:59,000 --> 00:04:02,800 They care about most you get on-demand access to their latest 75 00:04:02,800 --> 00:04:06,100 content thought, leadership insights, as well, as the 76 00:04:06,100 --> 00:04:10,100 exciting schedule of tech events running across all time zones. 77 00:04:10,700 --> 00:04:14,200 So by the devops our data science is your bus or you are 78 00:04:14,200 --> 00:04:17,500 fan of functional programming or all things Cloud. 79 00:04:17,600 --> 00:04:20,399 You can make real connections with people who share your 80 00:04:20,399 --> 00:04:24,600 interests head on over to skills method or Cam to become part of 81 00:04:24,600 --> 00:04:27,000 the tech community that matters most to you. 82 00:04:27,300 --> 00:04:30,500 It's free to join and you will find it easy to keep up with the 83 00:04:30,500 --> 00:04:36,100 latest tech Trends. Everyone welcome back to the new 84 00:04:36,100 --> 00:04:39,400 episode of the Attack original podcast today, I have with me 85 00:04:39,400 --> 00:04:42,900 someone named Michael Keeling. He's actually one of the four 86 00:04:42,900 --> 00:04:45,500 leaders in the tech industry. He has written a number of 87 00:04:45,508 --> 00:04:49,200 books, including design method. Today, we'll be talking a topic 88 00:04:49,200 --> 00:04:52,300 which I'm very interested in, which is architectural decision, 89 00:04:52,300 --> 00:04:57,200 records or some people know as a Dr. So Michael, today, I'm very, 90 00:04:57,200 --> 00:04:58,600 very pleased to have you on the show. 91 00:04:58,600 --> 00:05:00,300 So, looking forward for this conversation. 92 00:05:01,000 --> 00:05:02,200 Awesome. Yeah, thanks for having me, 93 00:05:03,100 --> 00:05:04,700 Michael. I always like to start my 94 00:05:04,700 --> 00:05:07,800 conversation by asking my guests to share more about themselves, 95 00:05:07,800 --> 00:05:11,100 may be telling the highlights or Turning Point In your career. 96 00:05:12,300 --> 00:05:13,900 Sure. You have a bit of a history so 97 00:05:13,900 --> 00:05:16,300 going way back. Graduating from college women 98 00:05:16,300 --> 00:05:19,000 marry with a computer science degree kind of a classic I 99 00:05:19,008 --> 00:05:21,400 guess, computer science math, set up getting into the software 100 00:05:21,400 --> 00:05:23,900 industry that way. The one thing from that degree 101 00:05:23,900 --> 00:05:26,500 that I was in the program there, I took a software engineering 102 00:05:26,500 --> 00:05:29,300 class my senior year and that was like, Far and Away. 103 00:05:29,600 --> 00:05:32,500 The most awesome class. I took probably the one course 104 00:05:32,500 --> 00:05:35,200 that stuck with me that I find myself applying after I got out 105 00:05:35,200 --> 00:05:38,800 into the real world, my first job working for US Department of 106 00:05:38,800 --> 00:05:42,900 Defense, Contractor there, I had the opportunity To work on what 107 00:05:42,900 --> 00:05:45,300 was called the Aegis modernization project which 108 00:05:45,300 --> 00:05:47,700 probably nobody knows what I'm talking about with that. 109 00:05:47,900 --> 00:05:50,000 But it was probably one of the largest model-driven 110 00:05:50,000 --> 00:05:52,800 architecture projects around certainly at the time, which is 111 00:05:52,800 --> 00:05:56,300 really cool opportunity to see these model-driven architecture. 112 00:05:56,300 --> 00:05:58,100 Model driven engineering practices. 113 00:05:58,100 --> 00:06:01,700 Firsthand on are real complex, distributed Mission critical 114 00:06:01,700 --> 00:06:04,500 system, the stuff we're building was shooting missiles, things 115 00:06:04,500 --> 00:06:06,100 like that. So pretty intense. 116 00:06:06,500 --> 00:06:08,500 So from there went back to University for software 117 00:06:08,500 --> 00:06:11,100 engineering to Carnegie Mellon but which is what brought me to 118 00:06:11,100 --> 00:06:13,800 Pittsburgh where I am. They still that Carnegie Mellon 119 00:06:13,800 --> 00:06:16,600 had the opportunity to take some cool courses and meet some 120 00:06:16,600 --> 00:06:20,000 awesome people, including Mary Shaw and David Garland did some 121 00:06:20,000 --> 00:06:23,800 reading courses with them and semester or so research with 122 00:06:23,800 --> 00:06:27,000 David and that was kind of what eventually led to the book 123 00:06:27,000 --> 00:06:29,300 design it. So a lot of digging into details 124 00:06:29,300 --> 00:06:30,300 there. Yeah. 125 00:06:30,300 --> 00:06:33,000 And since then been in Pittsburgh working for a local 126 00:06:33,000 --> 00:06:35,600 startup that was acquired by IBM and then within IBM, we were 127 00:06:35,600 --> 00:06:38,500 like reacquired, I guess by Watson. 128 00:06:38,800 --> 00:06:41,100 So working for one of the biggest companies around, I 129 00:06:41,100 --> 00:06:41,800 guess. At that point. 130 00:06:41,900 --> 00:06:45,100 Ain't got in pretty early, not too early but fairly early on 131 00:06:45,100 --> 00:06:48,000 the micro services and Cloud Tech Stacks. 132 00:06:48,200 --> 00:06:51,400 I was really an exciting time to be doing all that machine 133 00:06:51,400 --> 00:06:55,000 learning Ai, microservices. And then since then, in the past 134 00:06:55,000 --> 00:06:58,200 four years, I've been with a fintech called keaw be working 135 00:06:58,200 --> 00:06:59,500 in a really big companies. Great. 136 00:06:59,500 --> 00:07:02,400 But I felt like it was time to get back to startups so that's 137 00:07:02,400 --> 00:07:04,600 why I left and eventually mineral way back to a small 138 00:07:04,600 --> 00:07:07,000 company. So it's been quite a journey. 139 00:07:07,000 --> 00:07:09,600 So you started from US Department of Defense to 140 00:07:09,600 --> 00:07:13,600 startups to Big corporate Batman back to start up, thanks for 141 00:07:13,600 --> 00:07:15,400 sharing your journey. That thing is really 142 00:07:15,400 --> 00:07:17,600 interesting. So throughout your journey, I 143 00:07:17,608 --> 00:07:20,600 think you discovered this thing called architectural decision 144 00:07:20,600 --> 00:07:23,200 record. Oh, let's call it short ADR so 145 00:07:23,200 --> 00:07:25,400 maybe tell us more how was the story? 146 00:07:25,400 --> 00:07:28,700 How did you discover it and how you've been a prominent 147 00:07:28,700 --> 00:07:31,000 supporter of that, I guess? Yeah. 148 00:07:31,000 --> 00:07:35,300 So back on my IBM team. We were fairly small team, a 149 00:07:35,308 --> 00:07:38,500 really young team as well. So I was one of the more senior 150 00:07:38,500 --> 00:07:42,200 Engineers on the team, but most of the seven or eight, Purrs 151 00:07:42,200 --> 00:07:45,000 were right out of University. So maybe one or two years 152 00:07:45,000 --> 00:07:47,700 working in a professional software development I guess as 153 00:07:47,700 --> 00:07:50,200 I briefly alluded in my story, the beginning you know we were 154 00:07:50,200 --> 00:07:53,300 getting into cloud-based. Microservices we're getting into 155 00:07:53,300 --> 00:07:55,900 AI we were getting into cloud-based Technologies, search 156 00:07:55,900 --> 00:07:59,400 Technologies, the AI everything is moving really quickly and 157 00:07:59,400 --> 00:08:01,600 we're struggling with some of the basic knowledge, sharing 158 00:08:01,600 --> 00:08:04,100 basic design principles things like that. 159 00:08:04,100 --> 00:08:07,300 That I think a lot of teams struggle with but with us being 160 00:08:07,300 --> 00:08:10,500 fairly young and then really in a bit of a pressure grinder, 161 00:08:10,800 --> 00:08:11,800 there was a lot of pressure to deliver. 162 00:08:12,000 --> 00:08:14,500 Her and moves quickly at the time with early days of Watson. 163 00:08:15,000 --> 00:08:18,300 That's the situation I'm open and looking for any kind of new 164 00:08:18,300 --> 00:08:21,700 techniques to bring my team for getting us to think more about 165 00:08:21,700 --> 00:08:23,500 architecture. Think more about design. 166 00:08:23,800 --> 00:08:26,700 That's when I came across, this Twitter thread, one day it was 167 00:08:26,700 --> 00:08:30,200 net price sharing a tool that he'd written for recording. 168 00:08:30,200 --> 00:08:32,200 This thing called the adrs over the command line. 169 00:08:32,200 --> 00:08:33,700 Just a very simple command line tool. 170 00:08:33,700 --> 00:08:37,200 And like okay this sounds neat what are 80 ours right dig in 171 00:08:37,200 --> 00:08:40,400 and I find all this cool stuff that sounded really great. 172 00:08:40,400 --> 00:08:42,000 So brought that back to my team. Mmmmmm. 173 00:08:42,200 --> 00:08:44,800 Hey, found. This thing called a TRS to give 174 00:08:44,800 --> 00:08:47,900 it a try and of course, my team is raved like, yeah, let's do 175 00:08:47,900 --> 00:08:49,200 it. What city are? 176 00:08:49,500 --> 00:08:51,700 So I had to teach them all that. I guess learned myself because 177 00:08:51,700 --> 00:08:54,700 it was my first time with that. I guess that's the discovery and 178 00:08:54,700 --> 00:08:57,000 then bring it again to try and solve some problems. 179 00:08:57,800 --> 00:09:00,800 So, maybe in the first place for people, maybe who may not be 180 00:09:00,800 --> 00:09:03,000 familiar with this thing called ad office. 181 00:09:03,000 --> 00:09:05,500 Maybe what is the definition of ADR? 182 00:09:05,700 --> 00:09:07,800 Is there a good way to summarize? 183 00:09:07,800 --> 00:09:10,400 What is an ADR? Yeah, so the cool thing with a 184 00:09:10,408 --> 00:09:13,500 DRS, the Other way that we practice today comes from this 185 00:09:13,500 --> 00:09:17,800 blog post by Michael Nygaard. He wrote the release it book 186 00:09:17,900 --> 00:09:20,000 which I always think those are the companion book to my have 187 00:09:20,000 --> 00:09:22,400 design it. So he wrote this blog post that 188 00:09:22,400 --> 00:09:24,800 kind of describe this experience report this idea that he was 189 00:09:24,800 --> 00:09:28,100 playing with which was okay. What if we write down a single 190 00:09:28,100 --> 00:09:30,200 decision, the single architectural decision. 191 00:09:30,500 --> 00:09:33,300 And what if we do it, right it down, it's just a simple 192 00:09:33,300 --> 00:09:35,500 markdown, very simple kind of text file. 193 00:09:35,800 --> 00:09:39,500 What if we keep the format very straightforward in the style of 194 00:09:39,500 --> 00:09:41,700 a pattern like a design pattern from Christopher, Alex? 195 00:09:41,900 --> 00:09:44,700 Under, you know, if we describe the context of the world, the 196 00:09:44,700 --> 00:09:48,400 forces that are play maybe their business horses are technical, 197 00:09:48,400 --> 00:09:50,500 they could be political. These are the things that are 198 00:09:50,508 --> 00:09:53,200 kind of acting on our decision, what it is that we're going to 199 00:09:53,208 --> 00:09:55,700 do. And then as a result of applying 200 00:09:55,700 --> 00:09:58,600 this decision, describe the consequences again, very like, 201 00:09:58,600 --> 00:10:01,300 how does the world change after we've done this decision? 202 00:10:01,400 --> 00:10:04,200 But could be trade-offs? It could be quality attributes 203 00:10:04,200 --> 00:10:06,400 promoted. It could be new risks or 204 00:10:06,400 --> 00:10:09,700 benefits, so that's an easy are really in a nutshell, kind of in 205 00:10:09,700 --> 00:10:11,500 its Essence, really simple, text file. 206 00:10:11,900 --> 00:10:14,500 Describes the context, the decision, in the consequences of 207 00:10:14,500 --> 00:10:17,400 that decision. I think the real cool part. 208 00:10:17,400 --> 00:10:19,000 The thing that was really different because design 209 00:10:19,000 --> 00:10:20,500 decisions, architecture decisions. 210 00:10:20,800 --> 00:10:23,000 They've been around for probably five six years. 211 00:10:23,300 --> 00:10:26,000 At least the study of architecture decisions had been 212 00:10:26,100 --> 00:10:28,900 a focus in the research area for a number of years before nine 213 00:10:28,900 --> 00:10:30,400 guards. Blog post the thing that was 214 00:10:30,400 --> 00:10:33,000 different though was keep it simple and then put it in the 215 00:10:33,000 --> 00:10:36,100 Version Control repository put it right in your git repo next 216 00:10:36,100 --> 00:10:37,900 to the code. Those two things really 217 00:10:37,900 --> 00:10:40,100 different than what anybody in the architecture community. 218 00:10:40,100 --> 00:10:41,700 At least have been talking about up to that point. 219 00:10:41,900 --> 00:10:43,800 Point. So I guess there's a long answer 220 00:10:43,800 --> 00:10:47,900 coordinate ER is as we dive deeper later on, if I can just 221 00:10:47,900 --> 00:10:52,100 summarize in a little bit it is like a simple text-based 222 00:10:52,100 --> 00:10:54,200 decision, right? That's that you store in Version 223 00:10:54,200 --> 00:10:58,000 Control and you kind of like capture single decision or it's 224 00:10:58,000 --> 00:11:01,000 not like the very overarching architecture document that could 225 00:11:01,000 --> 00:11:04,400 be how many hundreds of pages long and it captures three 226 00:11:04,400 --> 00:11:07,000 things context. What is the context when you 227 00:11:07,008 --> 00:11:10,000 make the decision? And the decision itself, and the 228 00:11:10,000 --> 00:11:11,700 consequences may be the trade-offs. 229 00:11:11,900 --> 00:11:14,900 Maybe the few things that you consider during the discussion 230 00:11:14,900 --> 00:11:16,800 and you decide. And then you capture, what are 231 00:11:16,800 --> 00:11:18,400 the consequences of the decisions. 232 00:11:18,900 --> 00:11:21,600 So, thanks for sharing this in a good way, right now summarize 233 00:11:21,600 --> 00:11:25,600 format so people should consider a Dr. But what is the true 234 00:11:25,600 --> 00:11:28,000 objective of it? Is it just to capture decision 235 00:11:28,000 --> 00:11:31,000 records for people to refer back maybe in the next few years? 236 00:11:31,200 --> 00:11:33,800 They forget what they did and they just look back. 237 00:11:34,000 --> 00:11:37,100 Or is there any other different objectives that you think Adia 238 00:11:37,100 --> 00:11:41,200 could help videos are great for capturing those decisions? 239 00:11:41,200 --> 00:11:42,200 And yeah. Yeah you're right. 240 00:11:42,200 --> 00:11:44,500 That's one decision to the time which is really amazing and 241 00:11:44,500 --> 00:11:47,900 Powerful because one decision is easy and then you just do that 242 00:11:47,900 --> 00:11:49,400 every day and then you look back. 243 00:11:49,400 --> 00:11:52,400 And next thing you know you got 30 40 pages of documentation of 244 00:11:52,400 --> 00:11:54,400 all these great design discussions that have happened 245 00:11:54,400 --> 00:11:57,000 over the past however, many months and that's great. 246 00:11:57,000 --> 00:11:58,900 Like capturing these design discussions and kind of 247 00:11:58,900 --> 00:12:01,900 describing the rationale for the design is really important. 248 00:12:02,100 --> 00:12:04,800 But what I really like about a DRS and the thing that I think 249 00:12:04,800 --> 00:12:08,000 is actually even more important is how it facilitates that 250 00:12:08,000 --> 00:12:10,900 discussion about design and it really puts design kind of at 251 00:12:10,900 --> 00:12:13,800 the Forefront from Senator. So it's kind of putting your 252 00:12:13,800 --> 00:12:16,800 team in this amazing place of being, I guess, where you're 253 00:12:16,800 --> 00:12:18,300 talking about design, where you're talking about 254 00:12:18,300 --> 00:12:20,800 architecture, that's really where the magic starts to 255 00:12:20,800 --> 00:12:22,600 happen. Recording the decisions is 256 00:12:22,600 --> 00:12:24,800 great, but the fact that you're coming together as a team and 257 00:12:24,800 --> 00:12:27,800 talking about them and really focusing on that is even better. 258 00:12:28,000 --> 00:12:29,500 I don't know. That's me, I think that's even 259 00:12:29,500 --> 00:12:31,600 more important, perhaps, than the decision itself. 260 00:12:32,200 --> 00:12:34,400 So, yeah, I think you brought these good point about 261 00:12:34,400 --> 00:12:37,700 facilitating, the design. Maybe the discussion is self and 262 00:12:37,700 --> 00:12:40,400 the decisions. So not many engineers in the 263 00:12:40,400 --> 00:12:43,300 team, I think would Could be involved in traditional 264 00:12:43,300 --> 00:12:45,600 companies, right? They rely on architect, some 265 00:12:45,600 --> 00:12:48,500 architect teams or maybe some senior engineers in the team to 266 00:12:48,500 --> 00:12:51,200 decide for them and to come up with all these design decisions. 267 00:12:51,200 --> 00:12:54,100 But I think I like what you mentioned is that when you have 268 00:12:54,100 --> 00:12:57,400 this kind of probably Cadence or maybe practice together in a 269 00:12:57,408 --> 00:12:59,800 software engineering team, you kind of like spread the 270 00:12:59,800 --> 00:13:02,600 knowledge about good design. You put it in a phrase which 271 00:13:02,600 --> 00:13:06,600 makes good design inevitable in the team but maybe tell us more 272 00:13:06,600 --> 00:13:10,400 why every software engineer needs to be strong, in design 273 00:13:10,400 --> 00:13:13,400 and architecture. Us traditionally again, like I 274 00:13:13,400 --> 00:13:16,800 said, in some companies they rely on some senior Architects 275 00:13:16,800 --> 00:13:20,200 or software Engineers to make the decision for them, right? 276 00:13:20,200 --> 00:13:22,400 Yeah. So a lot of times, I guess a lot 277 00:13:22,400 --> 00:13:24,700 of things get to this unfortunate state, where 278 00:13:24,900 --> 00:13:28,600 architecture is done by somebody else, somebody else somewhere in 279 00:13:28,600 --> 00:13:30,800 the organization, you know, the so called Ivory Tower. 280 00:13:30,800 --> 00:13:34,000 Architect, I just hate that term so unfortunate, right? 281 00:13:34,300 --> 00:13:37,700 But 80 ours, it brings things that are very distant 282 00:13:37,800 --> 00:13:39,300 architecture. Somebody else's problem. 283 00:13:39,500 --> 00:13:40,700 It helps bring it closer to home. 284 00:13:41,200 --> 00:13:43,300 I think that's important. Orton for a number of reasons, a 285 00:13:43,300 --> 00:13:45,500 big one being that it's empowering. 286 00:13:45,800 --> 00:13:48,100 The fact that these 80 ours are close to the code. 287 00:13:48,200 --> 00:13:51,200 They're kind of simple text files that it's the team who 288 00:13:51,200 --> 00:13:52,700 supposed to be writing that than owning them. 289 00:13:53,100 --> 00:13:55,600 Suddenly, you're giving agency to the team to own their own 290 00:13:55,600 --> 00:13:57,600 architecture. And to be responsible for it, 291 00:13:57,800 --> 00:14:01,200 which is super powerful. This is important, because it's 292 00:14:01,200 --> 00:14:03,800 easy to make mistakes with architecture, especially the 293 00:14:03,800 --> 00:14:05,800 cloud-based systems that I've traditionally worked on. 294 00:14:06,300 --> 00:14:09,300 You might have a perfect design, something that's implementing. 295 00:14:09,300 --> 00:14:11,600 Exactly, the architecture that you want. 296 00:14:11,800 --> 00:14:15,100 One completely unaware could unravel that entire 297 00:14:15,100 --> 00:14:19,300 architecture. So, I've had cases where someone 298 00:14:19,300 --> 00:14:22,900 unbeknownst unaware that perhaps there were certain like layers 299 00:14:22,900 --> 00:14:25,700 in the architectural. They would come in and buy lead 300 00:14:25,700 --> 00:14:28,400 those layers and then in the process incur tremendous 301 00:14:28,400 --> 00:14:30,900 performance penalties that could like increase the cloud costs, 302 00:14:30,900 --> 00:14:34,300 the compute costs, things like that or introduce instability in 303 00:14:34,300 --> 00:14:36,900 some way, purely by accident. But you know bringing the EDR is 304 00:14:36,900 --> 00:14:39,500 closed. Now it's your responsibility as 305 00:14:39,500 --> 00:14:41,800 a developer to kind of be aware of these things and to think A 306 00:14:41,808 --> 00:14:44,300 little bit more carefully about what the architecture is and to 307 00:14:44,300 --> 00:14:46,000 follow it. Probably the biggest thing with 308 00:14:46,000 --> 00:14:49,000 all that is being empowered, you're able to move quicker, 309 00:14:49,100 --> 00:14:51,300 you're able to be more Nimble, the bit more agile. 310 00:14:51,600 --> 00:14:54,200 So you're not waiting on other people to make decisions until 311 00:14:54,200 --> 00:14:57,200 you what to do, as the developer has the architect, wearing both 312 00:14:57,200 --> 00:14:59,900 of those hats, all those things, you could to make the call Rich, 313 00:14:59,900 --> 00:15:03,000 your helps you to hopefully move a little bit quicker and be a 314 00:15:03,000 --> 00:15:06,000 little bit more agile as a team, which is another fantastic 315 00:15:06,000 --> 00:15:08,200 outcome. I think, I think they are also a 316 00:15:08,200 --> 00:15:10,700 couple of things, right? I know that some companies 317 00:15:10,700 --> 00:15:13,600 practice this, I've Tyler architecture and things like 318 00:15:13,600 --> 00:15:16,200 that producing, hundreds of pages of documents. 319 00:15:16,400 --> 00:15:20,100 But they are also aspects where some teams most likely in the 320 00:15:20,100 --> 00:15:22,100 startups. They don't actually capture 321 00:15:22,100 --> 00:15:25,400 those design decisions. So, tell us more about the 322 00:15:25,400 --> 00:15:28,100 danger situation of doing this practice. 323 00:15:28,100 --> 00:15:31,800 Not capturing anything down. Yeah, so this is a big 324 00:15:31,800 --> 00:15:33,000 discussion, a couple of weeks ago. 325 00:15:33,300 --> 00:15:35,800 I was at my first in-person conference since before the 326 00:15:35,800 --> 00:15:38,300 pandemic, which is great. We were chatting about the 327 00:15:38,300 --> 00:15:42,000 importance of rationale like with architecture using Fine 328 00:15:42,000 --> 00:15:43,600 structure in the code, you can see it. 329 00:15:43,800 --> 00:15:46,200 Sometimes you can recreate it. You can kind of make a 330 00:15:46,208 --> 00:15:48,200 reasonable sketch based on what you see in the code. 331 00:15:48,400 --> 00:15:50,600 But recreating what people were thinking. 332 00:15:50,600 --> 00:15:53,600 At the time, they made those decisions is kind of impossible. 333 00:15:54,100 --> 00:15:56,900 I guess there's the chesterton's fence, Parable, which 334 00:15:57,000 --> 00:16:00,700 approximately goes you're in the middle of a field and there's a 335 00:16:00,700 --> 00:16:03,300 fence in the middle of the field and you need to remove this 336 00:16:03,300 --> 00:16:05,400 fence. You want to remove it but it's 337 00:16:05,400 --> 00:16:07,300 here. Somebody put it here for a 338 00:16:07,300 --> 00:16:09,500 reason. So you kind of have to make a 339 00:16:09,500 --> 00:16:11,500 call. Was this thing here for a reason 340 00:16:11,500 --> 00:16:14,200 can Through the fence, or maybe it's not there for a reason at 341 00:16:14,200 --> 00:16:16,300 all, and it's perfectly. Ok to delete. 342 00:16:16,500 --> 00:16:19,700 So, getting back to code for teens, who, haven't reported 343 00:16:19,700 --> 00:16:22,100 design rationale, who, having kind of written down, really any 344 00:16:22,100 --> 00:16:24,100 documentation that all? That's what we end up. 345 00:16:24,100 --> 00:16:26,200 Seeing a lot of, right? You can recreate the structure, 346 00:16:26,400 --> 00:16:30,000 you can see the fence but you have no idea why it's there how 347 00:16:30,000 --> 00:16:32,600 it's safe to change. Whether it's ok to delete or 348 00:16:32,600 --> 00:16:34,200 not. Now we're going through a lot of 349 00:16:34,200 --> 00:16:35,900 that right now. So with a startup company 350 00:16:35,900 --> 00:16:38,800 growing really fast, we've got a lot of foam and not everybody is 351 00:16:38,800 --> 00:16:41,600 around anymore to explain exactly how the code got to pee. 352 00:16:41,700 --> 00:16:43,900 The way it is. So I think there's any finer 353 00:16:43,900 --> 00:16:46,700 appreciation, perhaps things like a DRS. 354 00:16:47,300 --> 00:16:50,000 So you mentioned about people leaving the church under 355 00:16:50,000 --> 00:16:53,200 retention in many companies. This is common, right? 356 00:16:53,200 --> 00:16:56,200 So people come in gold and I think the danger of not 357 00:16:56,200 --> 00:17:00,300 capturing the decisions like you sometimes will probably pop 358 00:17:00,300 --> 00:17:04,000 under white such things happen in the code and use really can't 359 00:17:04,000 --> 00:17:06,800 tell whether it's safe to delete it, safe to refactor and things 360 00:17:06,800 --> 00:17:09,400 like that. So maybe when we have a Dr, at 361 00:17:09,400 --> 00:17:12,000 least we have the context again, coming back to the That you 362 00:17:12,000 --> 00:17:15,400 mentioned the context and why decision was made and is there 363 00:17:15,400 --> 00:17:18,599 any trade-offs are consequences when the decision was made at 364 00:17:18,599 --> 00:17:22,400 that point in time I think when I read some of your articles as 365 00:17:22,400 --> 00:17:25,599 well I think there's one thing that I also picked interest in 366 00:17:26,000 --> 00:17:29,200 so we know that a dies, the good practice is to capture it along 367 00:17:29,200 --> 00:17:31,800 with the code in the Version Control in your article. 368 00:17:31,800 --> 00:17:34,900 You mentioned when the distance between developers and design is 369 00:17:34,900 --> 00:17:37,100 too big. Maybe, for example, you have 370 00:17:37,100 --> 00:17:39,700 like a separate document not in the source control. 371 00:17:39,900 --> 00:17:43,000 Developers perceive design as Having little value. 372 00:17:43,200 --> 00:17:45,700 So tell us more why you have this observation? 373 00:17:46,600 --> 00:17:49,700 Yeah, so it's back to that idea of the extent of the other, 374 00:17:49,800 --> 00:17:52,200 right? So when architecture is 375 00:17:52,200 --> 00:17:54,300 maintained and other documents or you know, in a different 376 00:17:54,300 --> 00:17:56,400 knowledge, repository of some kind, it kind of goes out of 377 00:17:56,400 --> 00:17:59,300 sight and out of mind, at least in my experience, it becomes a 378 00:17:59,300 --> 00:18:00,800 template that you just have to fill in. 379 00:18:00,900 --> 00:18:03,800 Because there's a policy that says you have to fill it in, not 380 00:18:03,800 --> 00:18:06,400 necessarily something that you really care about or try and 381 00:18:06,400 --> 00:18:09,800 take ownership over, bring the heat ERS into the Version 382 00:18:09,800 --> 00:18:11,600 Control. Repository, it creates this 383 00:18:11,800 --> 00:18:13,200 Asian. There's this idea of in 384 00:18:13,200 --> 00:18:15,600 psychology of an association principle, so things that are 385 00:18:15,600 --> 00:18:17,600 close together. If you value, one of those 386 00:18:17,600 --> 00:18:20,300 things and if you can associate other things to the thing that 387 00:18:20,300 --> 00:18:24,000 you value, then you'll end up liking all of those things that 388 00:18:24,000 --> 00:18:26,600 are kind of associated with it. So this is like a common sales 389 00:18:26,600 --> 00:18:29,500 technique. You'll see people who liked this 390 00:18:29,500 --> 00:18:31,800 movie. Also liked this product, they're 391 00:18:31,800 --> 00:18:33,900 trying to create that Association to bring you in to 392 00:18:33,900 --> 00:18:36,300 get you to like this other thing we could effectively do the same 393 00:18:36,300 --> 00:18:40,000 thing with design through a DRS for developers if you highly 394 00:18:40,000 --> 00:18:43,000 value the code and if the Code is the number one most important 395 00:18:43,000 --> 00:18:45,100 thing. Well, code is important. 396 00:18:45,100 --> 00:18:46,600 We put the code in Version Control. 397 00:18:46,800 --> 00:18:48,200 That's where all the important stuff goes. 398 00:18:48,400 --> 00:18:50,400 Hey, look at that. Let's put the ATR is in Version 399 00:18:50,400 --> 00:18:53,300 Control. It's like, okay, well since it's 400 00:18:53,300 --> 00:18:55,600 in Version Control that it must also be important to. 401 00:18:55,800 --> 00:18:58,100 So we've kind of created this association between design and 402 00:18:58,100 --> 00:19:00,500 code that at least gets the foot in the door. 403 00:19:00,800 --> 00:19:03,100 It gets the conversation, started about the importance of 404 00:19:03,100 --> 00:19:05,000 design. So many developers who are 405 00:19:05,000 --> 00:19:07,500 Skeptics architecture. Somebody else's problem, not my 406 00:19:07,500 --> 00:19:10,000 problem. Bring it in closer helps to at 407 00:19:10,000 --> 00:19:11,600 least kind of show that there is value here. 408 00:19:12,600 --> 00:19:15,700 And you captured is nicely. So things related to this, 409 00:19:15,700 --> 00:19:17,900 practice right Association techniques were developed, a 410 00:19:17,908 --> 00:19:20,900 start to Value architecture, decisions more. 411 00:19:21,100 --> 00:19:23,900 And I think you observe, therefore key Behavior changes. 412 00:19:24,000 --> 00:19:27,400 If we start practicing ADR more frequently, as part of the team 413 00:19:27,400 --> 00:19:30,900 culture, maybe can share more. What are these key Behavior 414 00:19:30,900 --> 00:19:33,100 changes that you observe. Yeah. 415 00:19:33,100 --> 00:19:35,500 So once we kind of create that Association and once we get 416 00:19:35,500 --> 00:19:37,600 developers, kind of talking about design and being willing 417 00:19:37,600 --> 00:19:40,000 to think about architecture, more actually, give these ADR 418 00:19:40,000 --> 00:19:41,600 things to try a couple of cool things. 419 00:19:41,700 --> 00:19:43,500 Start to happen. One of the first important 420 00:19:43,500 --> 00:19:47,100 things is building up kind of this, I guess almost social 421 00:19:47,100 --> 00:19:49,500 proof. So the most important person 422 00:19:49,500 --> 00:19:51,500 writing an ADR. If you're trying to bring a TRS 423 00:19:51,500 --> 00:19:53,500 and your team, the most important person is not you. 424 00:19:53,700 --> 00:19:56,500 It's actually the next person. If you're the only person 425 00:19:56,500 --> 00:19:59,300 writing edrs, nobody's really going to pay much attention but 426 00:19:59,300 --> 00:20:02,400 as soon as a second person starts contributing, that's got 427 00:20:02,400 --> 00:20:04,800 power. So now it's not just one person. 428 00:20:04,800 --> 00:20:06,400 We've got a group, the starting to form. 429 00:20:06,500 --> 00:20:08,600 So now you've got a lot of people were saying, btr's are 430 00:20:08,600 --> 00:20:10,700 important. Design is important, so that's 431 00:20:10,700 --> 00:20:13,900 one kind of area. Other people writing a DRS and 432 00:20:13,900 --> 00:20:16,200 that starts to kind of change the behavior little bit like oh 433 00:20:16,200 --> 00:20:18,000 everybody else is doing it, maybe I should do it. 434 00:20:18,400 --> 00:20:21,400 The next thing is the fact that these 80 hours are written down 435 00:20:21,400 --> 00:20:24,000 and then we rephrase them is important to wonder saying the 436 00:20:24,000 --> 00:20:28,800 decision part, we're saying, we will do XYZ, we will introduce a 437 00:20:28,800 --> 00:20:31,900 data layer and it will be the bottom most layer. 438 00:20:32,100 --> 00:20:34,400 Only the business layer is allowed to use it, maybe that's 439 00:20:34,400 --> 00:20:37,100 your decision. So you write that up, you write 440 00:20:37,100 --> 00:20:38,400 it down. You have other people on your 441 00:20:38,400 --> 00:20:40,900 team, review it through your pull request process, may be 442 00:20:41,200 --> 00:20:43,800 that It is, in a way. Forming a written commitment. 443 00:20:43,800 --> 00:20:45,500 It's like a promise. We made a decision. 444 00:20:45,500 --> 00:20:48,400 We will do this thing that we've decided because it's written 445 00:20:48,400 --> 00:20:51,100 down. It starts to form this Bond, 446 00:20:51,100 --> 00:20:53,000 almost like your word is your bond. 447 00:20:53,200 --> 00:20:55,700 You said we're going to do this thing and now you want to be 448 00:20:55,700 --> 00:20:58,100 consistent with the promise you made, which is another one of 449 00:20:58,108 --> 00:21:00,900 these psychological principles consistency principle. 450 00:21:01,400 --> 00:21:05,900 So what that ends up doing is teams feel more compelled almost 451 00:21:05,900 --> 00:21:09,200 to follow through on the designs that they're creating so we made 452 00:21:09,200 --> 00:21:11,300 a decision, we've written it down. 453 00:21:11,700 --> 00:21:13,500 Read it. We told everybody we're doing 454 00:21:13,500 --> 00:21:15,100 this. Now we're actually going to do 455 00:21:15,100 --> 00:21:17,900 it, which is pretty cool. All this kind of leads to 456 00:21:18,000 --> 00:21:20,500 building up more and more support I guess for this idea 457 00:21:20,500 --> 00:21:24,600 that hey, we're the kind of team who thinks about design where 458 00:21:24,600 --> 00:21:27,400 the kind of team who writes down decisions before we make them 459 00:21:27,700 --> 00:21:30,600 kind of self-identity, almost of the individuals on the team 460 00:21:30,600 --> 00:21:34,000 starts to change that itself, becomes almost reinforcing idea, 461 00:21:34,000 --> 00:21:36,800 which is very powerful either. There's a lot of really neat 462 00:21:36,800 --> 00:21:39,600 mechanisms built into this little tiny text document, which 463 00:21:39,600 --> 00:21:43,600 I think is really, really great. And you mentioned, like, coming 464 00:21:43,600 --> 00:21:45,700 back to the explanation. You did idea. 465 00:21:45,900 --> 00:21:49,500 So, the real value of ADI is not just to capture the design in 466 00:21:49,500 --> 00:21:52,300 that position control, but actually, you will transform the 467 00:21:52,300 --> 00:21:55,200 developers in the team to start, thinking more about design, 468 00:21:55,400 --> 00:21:58,400 maybe they will turn into architects in the team, right? 469 00:21:58,400 --> 00:22:01,200 So everyone will also become an architect because they're like 470 00:22:01,200 --> 00:22:04,600 making the decisions together. Maybe the overarching goal is to 471 00:22:04,700 --> 00:22:08,300 start changing the team culture themselves to think or care more 472 00:22:08,300 --> 00:22:10,800 about design before they actually jump into the code and 473 00:22:10,800 --> 00:22:12,900 write the code. I think this kind of thing, 474 00:22:12,900 --> 00:22:15,700 culture is very important because in some companies yet 475 00:22:15,700 --> 00:22:19,300 again, it's not visible. Everyone just do based on 476 00:22:19,300 --> 00:22:22,100 features functions or pressure from the business people. 477 00:22:22,100 --> 00:22:24,800 Stakeholder say I want this picture done but they don't 478 00:22:24,800 --> 00:22:27,500 think through the design. So I think one of the area of 479 00:22:27,500 --> 00:22:30,200 these area where it can help is actually to build this team 480 00:22:30,200 --> 00:22:33,300 culture. Why is it only lately quite 481 00:22:33,300 --> 00:22:35,000 popular? Because I think Michael Knight 482 00:22:35,000 --> 00:22:37,600 got wrote the book quite a number of years ago, but somehow 483 00:22:37,600 --> 00:22:40,800 this idea seems to pick up quite recently in many different 484 00:22:40,800 --> 00:22:43,300 companies. So if you can share, maybe your 485 00:22:43,300 --> 00:22:46,400 observation. Why that is so yeah, I've been 486 00:22:46,400 --> 00:22:47,900 really curious about that myself. 487 00:22:47,900 --> 00:22:49,200 So like why is everybody doing it? 488 00:22:49,200 --> 00:22:50,900 He's ours. Now, I think what it comes down 489 00:22:50,900 --> 00:22:54,000 to is so maybe a year or two years before the night guard 490 00:22:54,000 --> 00:22:57,200 blog post, Fleek reached in and a couple of co-authors whose 491 00:22:57,200 --> 00:23:00,000 name I'm forgetting. Wrote a kind of a challenge to 492 00:23:00,000 --> 00:23:02,700 the architecture Community about, we've had like the four 493 00:23:02,700 --> 00:23:06,200 plus one View, and we've got viewpoints and IEEE you points. 494 00:23:06,200 --> 00:23:08,700 All these things for a long time, it seems like decisions 495 00:23:08,700 --> 00:23:10,300 are becoming a thing. We need different ways of 496 00:23:10,300 --> 00:23:13,300 thinking about. The things that kind of got a 497 00:23:13,308 --> 00:23:15,300 lot of people thinking about this topic of architecture 498 00:23:15,300 --> 00:23:17,400 decisions. They were kind of two branches 499 00:23:17,400 --> 00:23:19,900 from that point. One was the architecture 500 00:23:19,900 --> 00:23:23,300 Community, they went very deep in View and view models. 501 00:23:23,500 --> 00:23:26,000 So there are a lot of people proposing, decisioning 502 00:23:26,000 --> 00:23:30,100 viewpoints things like that really powerful techniques, but 503 00:23:30,100 --> 00:23:33,400 also you have to know a lot. You have to have tooling fairly 504 00:23:33,400 --> 00:23:36,300 heavy weight to use Nygaard. It was kind of coming from the 505 00:23:36,300 --> 00:23:39,100 agile patterns tradition, his approach that he had kind of 506 00:23:39,100 --> 00:23:41,300 pitched out there very lightweight text-based. 507 00:23:41,600 --> 00:23:44,500 No barrier to entry. You just get started, using it. 508 00:23:44,800 --> 00:23:48,400 So I think that was kind of the invitation from my own 509 00:23:48,400 --> 00:23:51,200 experiences using it because there are few kind of guide 510 00:23:51,200 --> 00:23:52,900 rails to it. Takes a little bit of time to 511 00:23:52,900 --> 00:23:56,800 figure out how exactly it works. Those changing behaviors that we 512 00:23:56,800 --> 00:23:59,000 were just chatting about on teams that I've worked on the 513 00:23:59,000 --> 00:24:01,900 past. You're looking at six months to 514 00:24:01,900 --> 00:24:03,600 two years. Something like that is kind of a 515 00:24:03,608 --> 00:24:07,300 journey for, you know, introducing the abr's learning 516 00:24:07,300 --> 00:24:10,400 how to use the well, well developing the skills coaching, 517 00:24:10,700 --> 00:24:13,300 all that kind of stuff. To kind of develop a team who is 518 00:24:13,300 --> 00:24:15,000 able to do these things. I don't know. 519 00:24:15,000 --> 00:24:18,400 Just guessing it seems like a bunch of teams were probably 520 00:24:18,400 --> 00:24:21,100 picking up these techniques and the year or two or three after 521 00:24:21,100 --> 00:24:22,800 night guards blog post, you figure. 522 00:24:22,800 --> 00:24:25,400 It takes a year or two to kind of get used to it, trained up on 523 00:24:25,400 --> 00:24:26,900 it. And then from there, it sort of 524 00:24:26,908 --> 00:24:29,200 spreads as more and more people getting proficient. 525 00:24:29,500 --> 00:24:31,100 So I don't know one thought on it. 526 00:24:31,800 --> 00:24:34,100 Yeah, who knows. But anyway now it becomes like a 527 00:24:34,100 --> 00:24:35,800 trend in many of the tech startup. 528 00:24:35,800 --> 00:24:38,900 So maybe if a big company who value architecture decisions 529 00:24:38,900 --> 00:24:42,000 more and probably, they don't think the traditional No way of 530 00:24:42,000 --> 00:24:44,200 documenting. The architecture decisions was 531 00:24:44,200 --> 00:24:46,700 probably effective. Anyway, when we have these 532 00:24:46,700 --> 00:24:50,800 idiots, I assume if you are a team, which has been around for 533 00:24:50,800 --> 00:24:52,800 many years. If we make all the small 534 00:24:52,800 --> 00:24:56,200 decisions in the adrc, I guess it could be pretty long as well. 535 00:24:56,200 --> 00:24:58,400 It could turn out into hundreds of pages as well. 536 00:24:58,800 --> 00:25:02,400 So maybe any kind of tips here that things that should not be 537 00:25:02,400 --> 00:25:06,600 any ideas, how we should manage the ideas better instead of any 538 00:25:06,600 --> 00:25:09,100 new developer starting from zero and read. 539 00:25:09,100 --> 00:25:11,100 All the Ada has gonna take a long time. 540 00:25:11,800 --> 00:25:14,100 Yeah, well I guess a couple of interesting thoughts, what's the 541 00:25:14,108 --> 00:25:16,700 most tdrs of ever seen? So I've written a ton of edrs 542 00:25:17,100 --> 00:25:20,400 but I think in any particular software system of the most I've 543 00:25:20,400 --> 00:25:24,400 ever seen is maybe in the 30 to 40 range. 544 00:25:24,600 --> 00:25:27,600 So that's a solid year and a half of folks, diligently 545 00:25:27,600 --> 00:25:29,300 reporting decisions and it's a lot. 546 00:25:29,400 --> 00:25:31,300 I think it's the most I've ever seen most of the time it's in 547 00:25:31,300 --> 00:25:34,100 the dozen or so that you might see for particular module or 548 00:25:34,100 --> 00:25:36,000 something. Someone who owns which I guess 549 00:25:36,000 --> 00:25:38,000 when you like, take it all together, can be a lot. 550 00:25:38,300 --> 00:25:40,500 Gets that architectural decisions are made every day 551 00:25:40,900 --> 00:25:44,000 becoming a Aware of when you're making an architectural decision 552 00:25:44,000 --> 00:25:46,600 is probably the most important thing getting started. 553 00:25:46,900 --> 00:25:49,900 I think one thing I've seen recently happening as my teens 554 00:25:49,900 --> 00:25:53,300 have been kind of getting more sophisticated or more aware in 555 00:25:53,300 --> 00:25:56,000 thinking about design is when we started to look to other 556 00:25:56,000 --> 00:26:00,100 techniques to kind of blend with a trrs, my IBM teams were doing 557 00:26:00,100 --> 00:26:02,700 architectural hoisting, which is a really great technique. 558 00:26:02,700 --> 00:26:04,800 So they would not only write the EDR, but they would and 559 00:26:04,800 --> 00:26:08,100 introduced a framework to enforce certain decisions that 560 00:26:08,100 --> 00:26:10,800 were made or to enforce certain quality attributes that were 561 00:26:10,800 --> 00:26:13,500 desirable. I think a lot more design rules 562 00:26:13,500 --> 00:26:15,600 being implemented these days which is really great. 563 00:26:15,900 --> 00:26:18,500 There is a really great framework that my team is 564 00:26:18,500 --> 00:26:20,300 talking about just today called Arch unit. 565 00:26:20,400 --> 00:26:24,200 Those kind of J unit, testing or architecture, so taking 566 00:26:24,200 --> 00:26:27,800 something like that and combining it with a DRS is like 567 00:26:27,800 --> 00:26:31,500 a powerful combo, so thinking about modularity, and then 568 00:26:31,500 --> 00:26:35,600 blending techniques, blending ways of documenting decisions 569 00:26:35,600 --> 00:26:38,900 seems to be pretty powerful. You mentioned something about 570 00:26:38,900 --> 00:26:41,200 knowing when to create the a dies. 571 00:26:41,500 --> 00:26:44,600 How do you decide what kind of scope that warrants us to create 572 00:26:44,600 --> 00:26:47,100 an ADR? Because sometimes I believe if 573 00:26:47,100 --> 00:26:49,700 they don't get some kind of guidelines, they will just 574 00:26:49,800 --> 00:26:52,200 probably need to create many awesome. 575 00:26:52,200 --> 00:26:54,100 Like, they are not sure when to create right? 576 00:26:54,100 --> 00:26:57,900 So maybe any kind of guidelines, when should we create an idea 577 00:26:57,900 --> 00:27:00,500 for certain types of decisions, right? 578 00:27:00,500 --> 00:27:02,100 That's probably the number one mistake. 579 00:27:02,100 --> 00:27:03,900 I've seen new people who are new to 80 yards. 580 00:27:03,900 --> 00:27:08,000 Make is a lot of times you go from no documentation practice, 581 00:27:08,000 --> 00:27:11,300 like, nothing and then, oh my gosh, a TRS is amazing. 582 00:27:11,500 --> 00:27:14,500 That everything is in a Dr. Like literally anything that's going 583 00:27:14,500 --> 00:27:18,200 on on my team, we've got a heuristic, we've got a bunch of 584 00:27:18,200 --> 00:27:20,700 questions that we try and get people that answer does this 585 00:27:20,700 --> 00:27:23,300 decision deal with one of our most important quality 586 00:27:23,300 --> 00:27:27,100 attributes, does this decision bring on new technical debt. 587 00:27:27,300 --> 00:27:30,800 Does this decision materially change the structure in some 588 00:27:30,800 --> 00:27:32,600 way? Is this a decision that we can 589 00:27:32,600 --> 00:27:35,300 change our minds easily later? If it's something that's like 590 00:27:35,300 --> 00:27:37,900 easy to change later, maybe it's not so architectural. 591 00:27:38,100 --> 00:27:39,900 That's actually the first coaching Point. 592 00:27:39,900 --> 00:27:41,300 What is architecture? What is software? 593 00:27:41,400 --> 00:27:43,900 Texture, what does it mean to make an architectural decision? 594 00:27:44,200 --> 00:27:47,200 Yeah, the adrcs expose that immediately, you'll see things 595 00:27:47,200 --> 00:27:50,700 coming in, like, oh, we should name all the methods with a verb 596 00:27:50,700 --> 00:27:52,800 sighs. That's a good design decision, 597 00:27:52,800 --> 00:27:54,400 but it's not quite architectural. 598 00:27:55,100 --> 00:27:56,800 Thanks for sharing some of the heuristics. 599 00:27:56,800 --> 00:27:59,300 I think some people will find it very useful because sometimes 600 00:27:59,300 --> 00:28:02,700 it's not easy to gauge when we should create a Diaz, especially 601 00:28:02,700 --> 00:28:05,900 if we begin as you just learned from the books, it looks cool. 602 00:28:05,900 --> 00:28:08,700 Other side doing it, let's try. But when you try this, like, 603 00:28:08,700 --> 00:28:11,700 okay, when and I think you mentioned, also another Good 604 00:28:11,700 --> 00:28:15,200 practice in areas is to actually do a pan only like in Version 605 00:28:15,200 --> 00:28:19,600 Control of pain and not modify. Is there some situation where 606 00:28:19,600 --> 00:28:23,400 you need to modify or delete or how do you actually make a 607 00:28:23,400 --> 00:28:26,200 retrospective decisions? I guess, how do you do more? 608 00:28:26,600 --> 00:28:29,000 Yeah, so the idea behind the append only kind of decision 609 00:28:29,000 --> 00:28:30,500 log. It's really about helping you 610 00:28:30,500 --> 00:28:32,800 think about and helping you to capture that history. 611 00:28:33,100 --> 00:28:36,100 So you don't want to go back and say, like, oh well, we changed 612 00:28:36,100 --> 00:28:37,800 our mind. So let's just delete this old 613 00:28:37,800 --> 00:28:40,300 one and change it. Make us look really smart, that 614 00:28:40,300 --> 00:28:42,100 kind of a thing. Keep the old one. 615 00:28:42,300 --> 00:28:45,100 What you want to do is write a new decision in the update, the 616 00:28:45,100 --> 00:28:47,600 old one, to kind of point to the new one, even like take a 617 00:28:47,600 --> 00:28:49,400 cross-reference, they can reference back and forth. 618 00:28:49,900 --> 00:28:52,800 One of the thing by teens are doing recently, is adding a new 619 00:28:52,800 --> 00:28:55,400 section of the bottom of the decision, record for reflection. 620 00:28:55,700 --> 00:28:59,700 So in some cases, it may have been six months or a year, since 621 00:28:59,700 --> 00:29:02,700 we made a decision we go back and just kind of how did it work 622 00:29:02,700 --> 00:29:03,900 out? Did we actually get the 623 00:29:03,900 --> 00:29:05,700 consequences that we thought we were going to get? 624 00:29:05,900 --> 00:29:08,400 If you could go back in time and do something differently? 625 00:29:08,700 --> 00:29:10,200 Would you have still made the same decision? 626 00:29:10,400 --> 00:29:13,000 There are put it down on the Some of the file just out at the 627 00:29:13,000 --> 00:29:15,900 end of it is kind of sudden but ditional reflection, people get 628 00:29:15,900 --> 00:29:19,000 really uptight, I guess about. It's a pendolino, don't modify 629 00:29:19,100 --> 00:29:21,600 na fix the typos. It's okay. 630 00:29:21,800 --> 00:29:23,800 Nobody wants to spelling errors and things but don't like 631 00:29:23,800 --> 00:29:26,600 completely rewrite the thing that's kind of the spirit of 632 00:29:26,600 --> 00:29:28,500 what we're talking about. Yeah. 633 00:29:28,500 --> 00:29:31,900 So how about diagrams architecture, diagrams logical, 634 00:29:31,900 --> 00:29:35,800 diagrams data model diagrams and things like that and they also 635 00:29:35,800 --> 00:29:39,400 part of any ours. Oh yeah, diagrams are great. 80 636 00:29:39,400 --> 00:29:41,200 yards is all about effective communication. 637 00:29:41,400 --> 00:29:43,800 So anything that's gonna help you communicate effectively. 638 00:29:44,000 --> 00:29:46,600 Go ahead and put in that EDR. There's no hard and fast rule. 639 00:29:46,600 --> 00:29:50,500 That says, it has to be text only, so my team is a lot of 640 00:29:50,500 --> 00:29:52,800 times to keep it very light weight, but used to be in the 641 00:29:52,800 --> 00:29:54,800 increased pandemic, as you know, a picture of a white board, 642 00:29:55,000 --> 00:29:56,600 somebody would like sketch something up, take a picture of 643 00:29:56,600 --> 00:29:59,700 it, put it in the ATR, doesn't have to be anything fancy. 644 00:29:59,700 --> 00:30:02,900 Nowadays will see screen caps, a screen capture of like a Miro 645 00:30:02,900 --> 00:30:06,600 sketch or mermaid. Then GitHub, is added mermaid 646 00:30:06,600 --> 00:30:08,000 support. So people are starting to 647 00:30:08,008 --> 00:30:09,900 experiment with that, which is pretty cool. 648 00:30:10,200 --> 00:30:13,300 Kind of having rendered Last diagrams or sequence diagrams in 649 00:30:13,300 --> 00:30:15,000 the markdown. So that's pretty cool. 650 00:30:15,400 --> 00:30:19,700 But yeah, views are fantastic. That kind of reminds me in a way 651 00:30:19,700 --> 00:30:22,300 the decision log itself. It's like a change over time 652 00:30:22,300 --> 00:30:24,400 kind of view of the architecture. 653 00:30:24,900 --> 00:30:28,100 Another thing that we've had some interesting success with is 654 00:30:28,100 --> 00:30:30,900 re mixing so create a new document, maybe it's your 655 00:30:30,900 --> 00:30:34,400 security view of the system or your availability view of the 656 00:30:34,400 --> 00:30:36,900 software. You might add a couple of new 657 00:30:36,908 --> 00:30:40,600 diagrams, describe a few structures in that and then 658 00:30:40,600 --> 00:30:45,000 point to To the most important adrs that are related to that 659 00:30:45,000 --> 00:30:47,600 particular quality attribute for you're trying to describe. 660 00:30:47,900 --> 00:30:50,500 So, it's almost like a best of if you're interested in this one 661 00:30:50,500 --> 00:30:53,200 idea, this is where you go for it instead of only having that 662 00:30:53,200 --> 00:30:55,600 historical oldest to newest, kind of view of the world. 663 00:30:56,300 --> 00:30:59,300 Yeah, I think that's pretty useful because sometimes if you 664 00:30:59,300 --> 00:31:02,100 just Trace back it takes too long to actually form. 665 00:31:02,100 --> 00:31:04,000 What is the current view of the system? 666 00:31:04,200 --> 00:31:06,600 Yeah, it's interesting. Maybe not what you need right 667 00:31:06,600 --> 00:31:09,400 now. So, maybe since you have done is 668 00:31:09,400 --> 00:31:13,700 for many years now, I assume you have found certain patterns and 669 00:31:13,700 --> 00:31:16,000 anti patterns that maybe you can share, let's start with 670 00:31:16,000 --> 00:31:17,900 patterns. What are some of a good patterns 671 00:31:17,900 --> 00:31:20,600 that people should think about when they Implement ideas? 672 00:31:21,300 --> 00:31:23,000 We chatted about a couple of more ready, which I think is 673 00:31:23,000 --> 00:31:24,700 great. One of the patterns that I tend 674 00:31:24,700 --> 00:31:27,400 to encourage is really anything to get things started. 675 00:31:27,400 --> 00:31:31,100 So interesting stuff, a TRS-80 ours, they're lightweight, but 676 00:31:31,100 --> 00:31:33,500 sometimes In the Heat of the Moment, it's just a little bit 677 00:31:33,500 --> 00:31:36,100 too much work even for something so short as an AVR. 678 00:31:36,600 --> 00:31:39,800 But if you Least capture the stub, just like a very brief, 679 00:31:40,100 --> 00:31:42,500 what's the decision? And as many notes as you can 680 00:31:42,500 --> 00:31:44,800 about the rationale, it's at least a start. 681 00:31:45,000 --> 00:31:47,800 So that's a pretty good pattern. I think that I've seen in a lot 682 00:31:47,800 --> 00:31:50,400 of places. Another one, I think we kind of 683 00:31:50,400 --> 00:31:51,600 chatted about this briefly as well. 684 00:31:51,800 --> 00:31:54,800 I really love to use a DRS as a teaching tool away for kind of 685 00:31:54,808 --> 00:31:56,600 coaching. One of my favorite things with 686 00:31:56,600 --> 00:31:59,900 that is delegating to people saying like, hey, you write the 687 00:31:59,900 --> 00:32:02,800 ADR asking for volunteers, especially, folks, who maybe 688 00:32:02,800 --> 00:32:05,900 have never written one before and then letting them do their 689 00:32:05,900 --> 00:32:07,300 best, just letting me give it a try. 690 00:32:07,400 --> 00:32:08,800 Bye. And then sitting down and 691 00:32:08,800 --> 00:32:11,100 pairing with them afterwards, to kind of talk about asking 692 00:32:11,100 --> 00:32:14,100 questions or dig into the consequences, things like that. 693 00:32:14,300 --> 00:32:16,700 So there are I think pretty good pattern that I've seen really 694 00:32:16,700 --> 00:32:19,900 good tool for eight years. One more referencing 80 yards 695 00:32:19,900 --> 00:32:22,300 from the code. So that's probably like the best 696 00:32:22,300 --> 00:32:26,400 sign of when the team has kind of made it when you've kind of 697 00:32:26,400 --> 00:32:29,400 cross that Chasm, when you see comments in the code that are 698 00:32:29,400 --> 00:32:31,400 then referencing a TRS have been written. 699 00:32:31,700 --> 00:32:33,600 So you have this kind of nice cross perks, right? 700 00:32:33,600 --> 00:32:36,200 Like, you can see the structure in the code and then people are 701 00:32:36,200 --> 00:32:39,200 linking out to other document. And help describe the rationale. 702 00:32:39,500 --> 00:32:41,600 That's just huge. I really like that as a 703 00:32:41,600 --> 00:32:43,200 practice. And of course, it's all in the 704 00:32:43,300 --> 00:32:46,100 Version Control repository. So you know, when they copy it 705 00:32:46,108 --> 00:32:48,200 down, you'll be able to find it. It's all there. 706 00:32:49,000 --> 00:32:50,900 Yeah, I like it. When you say that the sign of 707 00:32:50,900 --> 00:32:54,200 the teams who made it them, some practicing a Diaz is actually, 708 00:32:54,200 --> 00:32:57,100 when they referencing it in many parts of the code as well. 709 00:32:57,400 --> 00:33:00,300 So it's not just a silo, one document that is maintained by a 710 00:33:00,308 --> 00:33:03,100 few people and the rest of developers, just write the code, 711 00:33:03,100 --> 00:33:04,500 right? So I think that's a nice way to 712 00:33:04,500 --> 00:33:06,700 put it. How about anti-patterns, so 713 00:33:06,700 --> 00:33:09,600 maybe you have I found some empty patterns along the way. 714 00:33:10,200 --> 00:33:11,800 Yeah. So some things that maybe don't 715 00:33:11,800 --> 00:33:13,400 go so well. So we chatted a little bit about 716 00:33:13,400 --> 00:33:16,300 everything is in a Dr. I've seen that happen on every single 717 00:33:16,300 --> 00:33:18,700 team. Probably another one, everything 718 00:33:18,700 --> 00:33:21,700 is not an AVR and that's okay for new folks. 719 00:33:21,700 --> 00:33:24,300 Especially something that I see is we'll just call it may be 720 00:33:24,300 --> 00:33:27,000 simple consequences, you'll have this great decision. 721 00:33:27,300 --> 00:33:29,700 You'll have a pretty good context and then you'll see like 722 00:33:29,700 --> 00:33:31,900 one consequence. It'll be like, because we 723 00:33:31,908 --> 00:33:34,400 thought it was good. It's like, oh my gosh, that's 724 00:33:34,400 --> 00:33:37,300 not a consequence or it'll be, sometimes even sillier than 725 00:33:37,700 --> 00:33:40,500 It'll be like the code will be more maintainable or something. 726 00:33:40,800 --> 00:33:42,600 Okay, well I mean, at least there's a quality attribute but 727 00:33:42,600 --> 00:33:45,200 it's just this one thing. So I think one of the things I 728 00:33:45,200 --> 00:33:49,000 really strongly encourage is digging for those consequences. 729 00:33:49,100 --> 00:33:53,000 So, go for at least three go for more than three and nearly 730 00:33:53,000 --> 00:33:55,100 always when that happens. When you really think about it, 731 00:33:55,100 --> 00:33:57,400 you're like stumped. It's like what could possibly 732 00:33:57,400 --> 00:33:59,400 happen, What? Trade-offs could there possibly 733 00:33:59,400 --> 00:34:01,600 be. And then all of a sudden, the 734 00:34:01,600 --> 00:34:05,400 dam will break ideals will flow, and you'll come up with five or 735 00:34:05,400 --> 00:34:07,200 six, more consequences and they're going to be the most 736 00:34:07,300 --> 00:34:09,900 Most interesting things that maybe you wouldn't have 737 00:34:09,900 --> 00:34:13,000 otherwise thought of this is where maybe you'll consider new. 738 00:34:13,000 --> 00:34:15,500 Technical risks. New engineering risks introduced 739 00:34:15,500 --> 00:34:19,199 by the change or particular quality attributes, promoted 740 00:34:19,199 --> 00:34:21,699 that maybe weren't a top of mind at that moment. 741 00:34:22,000 --> 00:34:25,699 So to few consequences, I think, is a pretty common anti-pattern. 742 00:34:26,400 --> 00:34:29,199 So, you mention about all these simple consequences and things 743 00:34:29,199 --> 00:34:32,199 like that. Cows, should we, as a team, make 744 00:34:32,199 --> 00:34:36,100 decisions together as an ADR? I imagine because there could be 745 00:34:36,100 --> 00:34:38,199 many practices like one And delegated. 746 00:34:38,199 --> 00:34:41,100 This make the decisions or is it like every time you want to make 747 00:34:41,100 --> 00:34:44,100 a Dia, you do team huddle? Many different practices. 748 00:34:44,400 --> 00:34:46,400 How should we make a good decision together? 749 00:34:46,400 --> 00:34:49,300 As a team in the form of a Dr. Maybe you can also cover this 750 00:34:49,300 --> 00:34:51,500 one. There's a lot of interesting 751 00:34:51,500 --> 00:34:54,900 ways I've seen teams to do this. So one of my favorites, I think 752 00:34:55,000 --> 00:34:57,000 is a lot of times. I'll see your team together in a 753 00:34:57,007 --> 00:34:59,000 whiteboard Jam. Everybody kinda at the 754 00:34:59,000 --> 00:35:00,800 Whiteboard, talking about different things. 755 00:35:00,800 --> 00:35:02,400 Everybody's throwing up different ideas. 756 00:35:02,700 --> 00:35:05,500 They're asking questions. Taking turns with the marker 757 00:35:05,500 --> 00:35:09,300 either physically or Actually we're all remote taking turns 758 00:35:09,300 --> 00:35:12,100 telling stories back and forth and walking through our diagrams 759 00:35:12,300 --> 00:35:15,200 when that happens sometimes but not always, but when it does, 760 00:35:15,200 --> 00:35:18,500 it's really beautiful. Someone will start taking notes 761 00:35:18,500 --> 00:35:21,200 to the side about things that folks are talking about. 762 00:35:21,200 --> 00:35:22,900 Just right there in the mirror of word. 763 00:35:22,900 --> 00:35:27,500 For example, these are the starts of the adrs in a 764 00:35:27,500 --> 00:35:29,700 whiteboard Jam like you're just going through probably three 765 00:35:29,700 --> 00:35:32,600 four Alternatives, different ways of structuring things and 766 00:35:32,700 --> 00:35:35,800 really walking through hard parts of the architecture it 767 00:35:35,800 --> 00:35:38,700 helps to talk that through. Have somebody to explain it to 768 00:35:38,700 --> 00:35:41,500 ask questions but then even better is when you have another 769 00:35:41,500 --> 00:35:44,400 person to record what you're saying because sometimes you're 770 00:35:44,400 --> 00:35:46,200 just not going to remember he's brilliant moments that you're 771 00:35:46,200 --> 00:35:47,900 having. I think that's one way I've seen 772 00:35:47,900 --> 00:35:48,600 it come together. Really. 773 00:35:48,600 --> 00:35:51,400 Well, I've seen that phenomenon also happened during like mob 774 00:35:51,400 --> 00:35:52,900 programming. So when you've got, like, a 775 00:35:52,900 --> 00:35:55,100 whole group of people together, working on the same code, at the 776 00:35:55,100 --> 00:35:57,500 same time, same kind of phenomenon happens. 777 00:35:57,800 --> 00:36:00,100 So, you'll be making design decisions without even realizing 778 00:36:00,100 --> 00:36:02,200 it. And that and another teammate 779 00:36:02,200 --> 00:36:05,000 will just kind of notice and jot down the notes. 780 00:36:05,000 --> 00:36:07,100 You know, kind of create almost a Proto idiot. 781 00:36:07,300 --> 00:36:10,000 Are ready to go. So there's I guess kind of two 782 00:36:10,000 --> 00:36:12,000 things. Is that a session last week? 783 00:36:12,000 --> 00:36:14,400 I was pretty interesting. We had a big question, so 784 00:36:14,400 --> 00:36:16,500 somebody posed a big important question. 785 00:36:16,900 --> 00:36:19,500 Believe it involved a certain API technology. 786 00:36:19,500 --> 00:36:21,900 I think it was GRCC, we were talking about and whether or not 787 00:36:21,900 --> 00:36:25,700 your PC was going to be allowed in a certain part of the 788 00:36:25,800 --> 00:36:27,500 architecture. Whether we would have our 789 00:36:27,500 --> 00:36:30,300 services offered year if you see interfaces or not in that part 790 00:36:30,300 --> 00:36:33,100 of the architecture with that, it was actually a mob all 791 00:36:33,100 --> 00:36:34,700 together. Working on. 792 00:36:34,700 --> 00:36:38,100 Just that one decision a shared Google Document People jotting 793 00:36:38,100 --> 00:36:41,100 down context and try to get the context laid out talking about 794 00:36:41,100 --> 00:36:43,100 like, what are the consequences, bring some real consequences in 795 00:36:43,100 --> 00:36:45,000 real time. That was really great. 796 00:36:45,100 --> 00:36:46,800 I think the most important thing that you still have to kind of 797 00:36:46,800 --> 00:36:49,300 have somebody go through the final document and kind of 798 00:36:49,300 --> 00:36:52,100 phrase, the ADR to share back to the groove, even with like a 799 00:36:52,100 --> 00:36:54,600 group effort, you still have to have one person, maybe two in a 800 00:36:54,600 --> 00:36:56,600 pair go through and actually like write it up. 801 00:36:57,200 --> 00:36:58,400 Yeah. Sometimes It's tricky in the 802 00:36:58,400 --> 00:37:02,200 discussion who will capture that may be summarized it because I 803 00:37:02,200 --> 00:37:04,500 think it takes some time as well to actually capture down the 804 00:37:04,500 --> 00:37:07,000 essence. So my goal has been a pleasure 805 00:37:07,000 --> 00:37:09,200 talking A about these ideas. I learned a lot. 806 00:37:09,400 --> 00:37:11,900 I'm sure all the listeners here will also learn from this 807 00:37:11,900 --> 00:37:15,100 composition but unfortunately due to time, we have to wrap up 808 00:37:15,100 --> 00:37:17,400 pretty soon. But I have one last question. 809 00:37:17,400 --> 00:37:20,500 Maybe this is like the sharing your own ideas, right? 810 00:37:20,600 --> 00:37:23,000 So what I call three technical leadership is them. 811 00:37:23,300 --> 00:37:25,900 It's something that I think it's like an advice for listeners. 812 00:37:25,900 --> 00:37:29,000 May be from your journey from the experience or maybe from 813 00:37:29,000 --> 00:37:31,000 your expertise. So what will be your three? 814 00:37:31,000 --> 00:37:34,000 Technical leadership wisdom. So I guess folks, we've worked 815 00:37:34,000 --> 00:37:36,300 with me for a while. My team is probably find this 816 00:37:36,300 --> 00:37:39,100 amusing. I have Catchphrases mantras. 817 00:37:39,200 --> 00:37:41,300 Maybe that's a better way to wear things that I tell myself. 818 00:37:41,600 --> 00:37:44,400 So one of those is get it working then get it working 819 00:37:44,400 --> 00:37:46,200 better. When do I tell myself this? 820 00:37:46,200 --> 00:37:48,500 Anytime I'm facing a really difficult problem. 821 00:37:49,000 --> 00:37:50,200 Maybe I don't know how to get started. 822 00:37:50,200 --> 00:37:51,700 Maybe it's intimidating in some way. 823 00:37:52,100 --> 00:37:54,600 First thing, let's just get it working, get something working 824 00:37:54,900 --> 00:37:56,700 at once that something is working then we can get it 825 00:37:56,700 --> 00:37:59,300 working better at it. Maybe it's back to my otd roots 826 00:37:59,300 --> 00:38:01,700 or something, you get something working to get working better. 827 00:38:01,700 --> 00:38:04,100 So there's one second bit of wisdom. 828 00:38:04,200 --> 00:38:06,200 Maybe is remember, you're not alone. 829 00:38:06,500 --> 00:38:09,800 This is I think Thing that is very thematic throughout design. 830 00:38:09,800 --> 00:38:12,300 It is this idea that like, we're all in this together with a 831 00:38:12,300 --> 00:38:13,700 great team, you can work together. 832 00:38:13,700 --> 00:38:16,200 Even on really hard problems and design is hard architecture is 833 00:38:16,207 --> 00:38:18,500 hard so just remember that you're not alone. 834 00:38:18,500 --> 00:38:21,400 I think is really important ask for help, ask questions and 835 00:38:21,400 --> 00:38:23,700 people will help and the end result will be awesome. 836 00:38:24,200 --> 00:38:26,900 Third, one chatting with my son ahead of time about this 837 00:38:26,900 --> 00:38:30,100 question and he encouraged this bit was so I think it's great. 838 00:38:30,200 --> 00:38:33,800 The Bill & Ted wisdom of be excellent to each other, I think 839 00:38:33,800 --> 00:38:36,600 that's just true. 100%. True design is hard 840 00:38:36,600 --> 00:38:38,600 architectures. You're putting yourself out 841 00:38:38,600 --> 00:38:41,600 there, you're asking for feedback a lot on these things. 842 00:38:41,900 --> 00:38:45,200 Just be kind to one another. Be excellent to each other help 843 00:38:45,200 --> 00:38:47,500 each other. Learn is such a huge thing. 844 00:38:48,300 --> 00:38:50,400 I liked the last one so be excellent to each other. 845 00:38:51,300 --> 00:38:54,900 Sometimes we develop this one to work in Silo, right? 846 00:38:55,000 --> 00:38:58,500 So I'll 0 and then very grumpy about things or very afraid or 847 00:38:58,500 --> 00:39:00,000 something but now just be excellent. 848 00:39:00,500 --> 00:39:03,100 Yeah, if we are kind to each other I'm sure we create a 849 00:39:03,100 --> 00:39:05,900 better Community, better kind of results together 100. 850 00:39:06,000 --> 00:39:08,000 You're not alone? Yeah, we In alone at the end of 851 00:39:08,008 --> 00:39:10,800 the day. So Michael for people who love 852 00:39:10,800 --> 00:39:13,200 this conversation, if they want to follow up with you ask more 853 00:39:13,200 --> 00:39:15,100 questions. Is there a place for them to 854 00:39:15,100 --> 00:39:17,700 find you online? Yeah, Twitter will probably be 855 00:39:17,700 --> 00:39:19,100 the best place to reach out to me. 856 00:39:19,200 --> 00:39:21,800 Probably easiest one. My name is Michael chilling on 857 00:39:21,800 --> 00:39:24,200 Twitter. Thanks for that again, Michael. 858 00:39:24,200 --> 00:39:27,100 Appreciate your time today. Hope you have a very good 859 00:39:27,100 --> 00:39:29,300 success in promoting, this idea, Sumo people. 860 00:39:29,300 --> 00:39:32,000 I know that you are writing a lot of blocks or papers 861 00:39:32,000 --> 00:39:35,400 recently, hopefully we can share that to people as well when this 862 00:39:35,400 --> 00:39:37,100 episode is released. So, thanks again. 863 00:39:37,300 --> 00:39:38,600 Or that. Yeah, excellent. 864 00:39:38,600 --> 00:39:39,600 Thank you very much for having me. 865 00:39:39,600 --> 00:39:44,400 This was great. Thank you for listening to this 866 00:39:44,400 --> 00:39:47,800 episode and for staying, right until the end if you highly 867 00:39:47,800 --> 00:39:50,200 enjoyed it. I would appreciate if you share 868 00:39:50,200 --> 00:39:52,500 it with your friends and colleagues who you think would 869 00:39:52,500 --> 00:39:55,000 also benefit from listening to this episode. 870 00:39:55,200 --> 00:39:58,000 And if you are new to the podcast, make sure to subscribe 871 00:39:58,000 --> 00:40:00,500 and leave me your valuable review and feedback. 872 00:40:00,700 --> 00:40:03,700 It helps me a lot in order to grow this podcast better. 873 00:40:04,100 --> 00:40:07,000 You can also find the full show notes of this conversation on 874 00:40:07,000 --> 00:40:08,900 the episode page at tackling journal. 875 00:40:08,900 --> 00:40:12,500 The death website, including the full transcript With interesting 876 00:40:12,500 --> 00:40:15,600 quotes and links to the resources mention from the 877 00:40:15,600 --> 00:40:18,400 conversation. And lastly, make sure to 878 00:40:18,400 --> 00:40:20,700 subscribe to the shows mailing list on package. 879 00:40:20,700 --> 00:40:24,300 You know, dot f to get notified for any future episodes. 880 00:40:24,700 --> 00:40:27,200 Stay tuned for the next technology, you know, episode. 881 00:40:27,500 --> 00:40:29,100 And until then goodbye.