The Documented SDLC: Why Every Team Needs One (and When)

0:00 Brad: What are the typical features we would expect to see in a basic SDLC?

0:22 Scott: And welcome to another edition of How Many CTOs Does It Take? My name is Scott Porad and this is my trusty co-host,

0:29 Brad: Brad Haftigaub.

0:31 Scott: Brad, normally we try to avoid

0:36 talking about the date in these podcasts because sometimes they get shuffled out of order in how we release them but today I think there is an important and time sensitive topic for us to discuss now I know you are a music lover

0:51 Brad: Yeah.

0:52 Scott: I know you're a musician.

0:53 Brad: I am.

0:54 Scott: I think you even owned your own record label for a while.

0:58 So the most important question of the day is,

1:01 have you listened yet to the new Taylor Swift album?

1:07 Brad: I have not.

1:09 I

1:09 Scott: You

1:09 Brad: have

1:09 Scott: have not.

1:09 Brad: I have been busy listening to other musicians that I recently discovered and that have been really fun and have really exciting. I'm actually in the middle of of this month.

1:22 I'm going to so many concerts and that's been an opportunity to see bands that I've known for about for a while, but never seen live before.

1:30 And then the opening bands are always a nice little surprise because you.

1:34 Because you see you go there for the headliner, but you see an opening band you're like, oh shit,

1:38 they're pretty good, too

1:39 Scott: A hundred percent.

1:41 I got a lot of questions for you in my music festival going days,

1:44 I always like to go early in the day when it's not crowded,

1:47 you can wander around and you get a smorgasbord of bands you never heard before hear three or four songs from each of them.

1:53 So I'm curious to know what you're listening to that you like right now.

1:56 And I'm sure all of our tech loving nerds out there kind of know about this too.

2:01 But what are you listening to right now that you're excited about and what are you going to see?

2:06 Brad: Well, let's see.

2:06 I went to go see last week I saw a really fun band,

2:13 JVB, Joey Valance and Bray. They're a fun hip hop band that blew up on TikTok a couple years ago with their Punk Tactics song.

2:26 And I got to see them live. I actually went to that show with my youngest.

2:31 uh child uh who's in you know who's a gen z or so she had fun she's like dad they're they're playing all the gen z bangers and it was fun they're super fun hip-hop band um and uh

2:42 Scott: Out of curiosity,

2:43 where was that show at?

2:44 Brad: that was at the show box um and it

2:47 Scott: Market

2:47 Brad: was all ages

2:48 Scott: or Shoto?

2:48 Brad: it was at the market um and it was all ages so but we but we're both over 21 so of course we hung out in the bar area and and had a good time

2:58 Scott: For all of our listeners who are not in the greater Seattle area,

3:01 they need to know that the Showbox Market is the best club venue in Seattle, in my opinion.

3:07 Brad: It's pretty great.

3:08 Scott: It's really great.

3:10 Okay,

3:10 Brad: And then

3:10 Scott: who else

3:10 Brad: I

3:10 Scott: did you see?

3:11 Brad: saw this week I saw the band Softplay was the headliner.

3:16 They had an opener,

3:18 Kenny Hoopla, who I'd never heard of. And Kenny Hoopla was way more fun

3:25 Scott: That's

3:25 Brad: than

3:25 Scott: great.

3:25 Brad: I for just a random opener.

3:27 This is a good time. This is a really good time.

3:29 Scott: You saw the who?

3:31 Brad: Saw The Who on their supposedly last tour ever,

3:34 but I've gone to at least three Who concerts that were their last tour ever,

3:38 so it's hard to track, but this one looked like it really was going to be their last tour ever.

3:43 Scott: I have this friend who the very first concert he ever went to was I think in 1982 or 1981 or something like that and it was the Who Farewell tour.

3:55 Brad: Nice, yeah,

3:55 exactly. It was the one with the clash.

3:58 I

3:58 Scott: I

3:58 Brad: can't would even imagine. yes

3:59 Scott: I was like, I was too young to know.

4:01 Brad: that was that was that was a that was also a farewell tour anyway uh and then up next is turnstile with emil and the sniffers uh speed and um some other opening band and then after that we've got uh the super suckers and then um heat and boss all all random shows i'm gonna go see

4:23 Scott: It is fall music season for you. Please tell me that a meal in the Sniffers is a punk band.

4:28 Brad: Oh yeah, for sure.

4:29 A meal in this.

4:29 Scott: Because

4:29 Brad: They're from

4:30 Scott: what a great punk band name.

4:32 Brad: they're from Australia and they are pretty sure they're Australian, not New Zealand. Maybe they're Kiwis, but they're either Kiwis or they're Aussies and they're just like rowdy pub punk rock.

4:44 And so lots of fun.

4:47 Scott: Love it. Well, I've seen some music lately.

4:49 Brad: Yeah, tell me. By the way, we're turning this into the How Many CTOs Musical Podcast.

4:54 Scott: It's really true.

4:56 I was in California last weekend and saw three shows at the Hollywood Bowl.

5:03 I had never been to the Hollywood Bowl before.

5:08 The sound was excellent.

5:09 I saw two nights of LCD sound system.

5:13 Brad: Oh,

5:14 Scott: which

5:14 Brad: yeah,

5:14 cool.

5:14 Scott: is a strong recommend love

5:16 Brad: Yeah,

5:16 Scott: those

5:16 Brad: totally.

5:16 Scott: love them and i saw one night of big thief

5:21 Brad: Okay, cool.

5:22 Scott: which all the kids know and love big thief

5:25 Brad: Yeah.

5:26 And so all this music and we need have you listened to the new Taylor Swift album?

5:31 Scott: I have not yet,

5:32 Brad: but Okay.

5:33 Scott: after we are done recording today,

5:35 I will indeed put it on and listen to it.

5:37 Brad: All right.

5:38 Scott: I don't know if I would go as far to say as I'm a Swifty.

5:42 I think to be a Swifty,

5:43 you've got to know the lyrics to all the songs.

5:45 I don't really know that,

5:46 but I'm a fan of Taylor Swift.

5:48 I am impressed with her as a musician and an artist and overall just a.

5:56 a force in the entertainment industry.

5:57 Brad: I definitely would agree with that statement. I think she's an amazing entrepreneur.

6:03 I think she's amazing.

6:07 She's incredibly smart and deliberate in her creativity.

6:13 So that part,

6:14 I'm.

6:16 I'm in alignment with I

6:17 Scott: Now, I saw Taylor Swift. Was it last summer that they had the big Eras tour or was that like 15 months ago

6:24 Brad: was think that

6:24 Scott: the

6:24 Brad: that was

6:24 Scott: big Eras

6:24 Brad: like yeah.

6:25 Scott: tour?

6:25 I went to see the Eras

6:27 Brad: Oh,

6:27 Scott: tour.

6:27 Brad: wow.

6:29 Scott: Yeah,

6:29 I just thought to myself, this is like a cultural moment and I just want to see it. I just want to see what this is all about.

6:39 And I was blown away.

6:41 And I'll tell you, I was blown away by a few things.

6:43 The fans are just out of this world.

6:45 She has such an amazing relationship with her fans and super positive.

6:52 It was a giant sing-along. I mean, she could have just got up there and been like,

6:55 okay, we're going to sing this one now,

6:57 everybody.

6:57 Like, I think I went with one of my kids and like we were the only people in there that didn't know every word,

7:03 Brad: It's

7:03 Scott: every

7:03 Brad: so funny

7:03 Scott: song.

7:03 Brad: you say that because when we were at the Soft Play show,

7:07 uh on tuesday and uh the opening band i told you was this band kenny hoopla the crowd there was clearly a crowd was there for the opening band and they knew all the words and i turned to my buddy and i was like i forgot to do the homework

7:27 Scott: One last box to check here. Are you familiar with a band from England called Pulp?

7:33 Brad: Oh, as in

7:34 Scott: Oh,

7:34 Brad: like, I don't think so. I've not heard of them.

7:37 Scott: okay.

7:38 Brad: Check them out.

7:40 Scott: I have no idea.

7:41 They were the opener for LCD Sound System.

7:47 We were walking in towards the end of after their set was over the first night.

7:52 We didn't go to see them the first night and there were people walking out like people just came to see the opener,

7:57 Brad: Oh, yeah,

7:58 Scott: which

7:58 Brad: for sure.

7:58 Scott: was doesn't happen very often.

8:00 And I guess this is a band,

8:02 you know, they're closer to our age or they're a little bit older and they're sort of on a little bit of a reunion.

8:09 And I

8:09 Brad: There you

8:10 Scott: don't

8:10 Brad: go.

8:10 Scott: I thought maybe you'd heard of them. Well,

8:11 Brad: All right.

8:11 Scott: OK,

8:12 the music section.

8:13 section of how many cto's does it take is over we'll

8:16 Brad: All right.

8:16 Scott: move on to the software section of the party it's like a mullet we're going to go to the front of the haircut now and

8:27 Brad: This is up front party in the back.

8:29 Scott: Business upfront,

8:30 party in the back. So we got business to talk about.

8:32 And today,

8:33 I think our topic is the SDLC,

8:36 the software development life cycle.

8:38 And I think specifically what you told me you were interested in discussing was the documented SDLC,

8:46 the thing that's written down.

8:48 Brad: Yeah, I mean, presumably,

8:50 whether you write it down or not, every team is following some kind of a life cycle.

8:57 Scott: Somehow it gets done.

8:58 Brad: it's done somehow yeah and i just i think it's interesting right like i um

9:04 I've worked with ventures of all different sizes,

9:08 right,

9:09 from,

9:10 I mean, I guess I haven't, I mean, the largest,

9:12 the largest company I've ever worked for had 2000 employees, but so I've never been bigger than that, which obviously there's some, you know, the bigger ventures out there are even bigger.

9:21 But, you know, everything from two guys in a garage to, you know, 2000.

9:27 And I think it's interesting that.

9:29 that there's there's clearly an inflection point where at some point you look around and go oh gosh we should probably write this down how we're doing this and i was just kind of curious about picking your brain scott i know that you and i both worked at 98.6 together where i think we were both really impressed with the the sort of the the you

9:54 thoroughness of the documented SDLC that they had but I just kind of wanted to chat a little bit about like when do you need one why would you need one what are the core elements that need to be included in it like if I'm just a one guy in a garage with the AI coding agent should I think about my SDLC

10:15 Scott: I mean,

10:16 maybe.

10:17 actually come to think of it I mean I guess once you go start to make yourself a deploy script then you're thinking about it aren't you you're

10:26 Brad: Totally.

10:26 Scott: thinking about how do I get this software off my I guess as soon as you decide to commit the code to a repo you're thinking about an SDLC right

10:36 Brad: Yeah.

10:36 Scott: because that's like conceptually

10:38 Brad: Yeah.

10:39 Totally.

10:39 Totally. Well,

10:40 what have you found?

10:41 Scott: Well,

10:41 I want to talk about what we experienced at HealthCo.

10:44 I came in there and the SDLC was already in place and it was pretty robust.

10:51 And what I think I appreciated most about it was two parts.

10:56 One was that it was a

11:03 It was like a tool for retrospectives, if that makes sense.

11:07 What I mean is, if something went wrong,

11:10 the team would ask, well, what does our STLC say about this? And if it was silent or if it didn't say how to handle this, oh, that's something we need to come to agreement on how we handle this situation.

11:22 And so it almost became a repository for working agreements for how we were going to work together. And then the other thing...

11:29 I appreciated about it.

11:31 There was an owner of the SDLC and,

11:34 you know, there was like a quarterly amendment and update process.

11:38 It was kind of like the Constitution.

11:39 People could propose amendments and then I guess there was a committee of people who approved them. I don't really know how that process flowed, but and then maybe it was more RFC thing or something.

11:49 I'm not really sure.

11:50 But and then and then they were sent out and it was updated and it happened every quarter.

11:56 So as we learned during the quarter,

11:58 oh, here's a mistake we made, here's a mistake we made, here's a way we could do it better, then we sort of codified that.

12:06 So that's what I liked about it there,

12:07 I think.

12:08 It existed there for, well, I would imagine it existed there for two reasons.

12:14 One is a compliance reason.

12:16 You know, there's lots of compliance regimes or lots of them, but there's some compliance regimes that say you got to have it, get to have documented how you make software.

12:23 And then I think the other was they were doing healthcare and the quality was really important for them.

12:28 And so they wanted to have a consistent process.

12:31 And I remember the, I don't remember the exact words, but the preamble.

12:35 that was written at LCLC, which said something along the lines, which is, you know, software development is an inherently complex and ambiguous process.

12:50 It's a creative process.

12:53 To the extent that we can standardize any parts of it and we can minimize the complexity and simplify it and make our jobs easier.

13:02 And I appreciated that it made that made sense to me.

13:06 So those are all things I appreciated about it there.

13:10 Now you ask when, when should you have one?

13:12 Brad: Yeah.

13:13 Scott: That's a great question.

13:17 I think that.

13:20 It's probably a good idea to have one under a few circumstances.

13:25 One is if you're hiring pretty rapidly.

13:28 So like as you're bringing more and more people on,

13:31 again,

13:32 it comes back to that repository of working agreements.

13:36 Like so if somebody shows up, they can kind of have an understanding of like,

13:39 this is how we do it here.

13:41 Right.

13:42 And so if you're hiring rapidly or I think even if you have a environment where you need consistency across your teams or you want consistency across your teams, even if you're not hiring rapidly.

13:55 And I would suspect there's a number and that number is probably between like I'm going to guess seven and 15 people where, you know, probably with 15 people, you can still sort of get everybody in a room and say,

14:07 hey.

14:07 Hey, gang,

14:08 this is how we're going to do it.

14:09 But you start to get to that 20, 25 number,

14:12 it gets a little trickier to maintain that consistency just verbally,

14:16 right?

14:17 Brad: Yeah.

14:17 Scott: The sort of oral tradition starts to break down.

14:20 Brad: Yeah.

14:23 Scott: It still is maybe somewhere in those ranges is where I think it could be valuable.

14:28 And I know that the company I'm at right now does not have a written out COC and we're working to get one in place. And the approach we're taking is, I mean, it's happening. Software development has been happening at this company for 15 years.

14:44 I we started by just saying well let's just write down how it works now like let's not try to prescribe some new fancy way we want to do it let's just literally just

14:53 How do you do it?

14:54 Brad: Yeah,

14:54 Scott: So go

14:54 Brad: just document.

14:54 Scott: ask the question.

14:55 So go ask the question.

14:57 So when someone has an idea,

14:58 how does the, to use the proverbial, how does the build become a law around here?

15:02 Brad: Yeah,

15:02 Scott: You know, what,

15:03 Brad: totally.

15:03 Scott: just what are the steps?

15:05 And then we can go ask the question,

15:07 okay,

15:07 where do different teams do it differently?

15:09 And we want to make it consistent,

15:10 or maybe we don't mind that it's different on different teams.

15:13 What do we want to improve,

15:14 et cetera, et cetera.

15:15 But I think that's where you start is.

15:18 Uh,

15:18 you know, how do you do it now?

15:22 Brad: I think that makes a lot of sense. So how do you do it now?

15:26 And I think that, you

15:30 know, when I think about the do you need one and I first of all agree with you that like just writing down what you're already doing is probably the easiest way to make one.

15:41 I think that.

15:42 I want to kind of try to more explore like I love that you're saying like hey it's kind of just the way we do things and there's a there's a certain number of people that once you have that many people you you can't just use oral tradition to keep everybody kind of on the same page you have to like you have to have some other better way than just remind everybody that we we tell we see what we're doing we act and we tell each other like write it down it's easier um it strikes me that there's

16:08 Well, actually,

16:10 let me ask a question about this. So I'll make the following statement.

16:14 I would think that if you were going to do some kind of a compliance certification compliance regime like SOC 2 or HIPAA or something like that,

16:24 then those are those are often going to have like expectations and requirements around

16:29 Scott: Mm

16:29 Brad: things

16:30 Scott: -hmm

16:30 Brad: like data security.

16:32 OK.

16:34 And one of the things that certainly matters about how you write software is how you make sure that you don't have either mistakes made or rogue actors within your organization,

16:55 which are somehow jeopardizing.

16:59 Data security.

17:00 Right.

17:00 Scott: Mm-hmm.

17:01 Brad: So to me, that feels like one of the places where no matter how big you are,

17:06 you probably might have to have something written down to guard against that.

17:14 to manage data security.

17:17 Scott: Yeah.

17:17 Brad: So let me ask you that question.

17:19 In a world where it's never been written down as an official software development lifecycle document,

17:28 is there – am I over-subscribing to this SDLC concept?

17:37 or you know just just essentially an sdlc almost immediately exists the moment that you have some kind of a security or an audit policy like you and i decided that's just two of us in the garage but we agree like scott you never check in code unless i code review it and i never check in code unless you code review it like is that to me already almost feels like the beginnings of an sdlc

17:58 Scott: There you go.

17:59 Right. And, you know, from the auditor's perspective,

18:03 they're going to want to know, typically,

18:05 they want to know, you know, was this change to the system essentially approved?

18:13 Did some person in authority authorize this change?

18:19 And they just want to have a...

18:23 The words clean my mind is trace log,

18:25 but that's not really what

18:25 Brad: A

18:25 Scott: they mean.

18:26 Brad: paper trail.

18:26 A digital paper trail.

18:27 Scott: They want to have some, okay,

18:29 here's a change.

18:31 Show me who made the change. Show me who approved the change.

18:33 Right.

18:35 And your SDLC document would say,

18:37 well,

18:37 this is who approves changes and this is who makes changes.

18:41 And then an auditor would look at that and say, OK,

18:43 well, prove to me this happened.

18:45 And,

18:45 Brad: Yep.

18:46 Scott: you know, maybe it's something as simple as,

18:47 well, the person who made the change is whoever created the poll request and the person who authorized it is whoever reviewed it.

18:57 You can go look in our GitHub and see that every change has an author and an authorizer, right?

19:01 Brad: Yep.

19:02 Scott: And then they might ask,

19:03 well,

19:03 okay,

19:04 how are those, why are those reviewers qualified or, you know, who authorized the reviewers,

19:09 right?

19:11 You know, some companies might say, oh, well, all engineering managers can be approvers or all senior engineers can be approvers or something.

19:19 Maybe you have some criteria,

19:20 but if it's just the two of us and we wanted to be some sort of SDLC compliant,

19:24 you know, or, you know, SOC 2 compliant or whatever all the different frameworks are out there,

19:29 we would just say,

19:30 hey, well,

19:31 every PR is going to get approved by one of us and by not the person who wrote it, a different person who wrote it. In fact, there's a checkbox, I think, there.

19:40 Brad: And

19:40 Scott: You'd

19:40 Brad: GitHub

19:40 Scott: have you

19:40 Brad: enforce

19:40 Scott: can,

19:40 Brad: that

19:41 Scott: yeah,

19:41 Brad: must

19:41 Scott: PR, they call it a, yeah,

19:43 Brad: be approved and can't be approved by the author like that.

19:46 Scott: there's a name for those restrictions,

19:49 but it doesn't matter.

19:50 Brad: Yeah

19:50 Scott: The detail doesn't matter.

19:51 So they kind of even enforce that in there.

19:53 Yeah, I think that's what the compliance regimes want.

19:56 They want to know, like, show me the provenance of this chain.

20:00 Brad: Right.

20:00 Scott: Yeah.

20:01 Brad: Because if someone comes along and says you're embezzling money from this company,

20:06 you know, the classic office space,

20:08 there's pennies going to your account.

20:09 They want to know how that happened.

20:11 And if so-and-so in accounting who's an authorized approver said it was OK,

20:14 then.

20:15 Guess it's okay.

20:17 Scott: Right.

20:17 You know, another place where I think this comes in, and I'm not sure this was, I don't know for sure if this has ever been the motivation or if this is necessarily something you want to protect against, but I have a feeling that there can also be a.

20:35 Like maybe the reason that we ended up getting really we end up really getting specific about who's asking for the change and was and did the change go through enough review or did the change, you know, like was there a proposal?

20:48 Was the proposal reviewed?

20:50 Did the proposal then have an estimation?

20:52 You know, you and I talked recently about the notion of quality and how quality begins with like, do we even understand what we're building?

21:00 Brad: Right.

21:01 Scott: So I'm just kind of curious,

21:03 where do you think the role of where do you think the role of the upstream from developers starting to think about code,

21:12 where does that live in the software development lifecycle at HealthCo?

21:16 There was a big section of the document was was well before developers ever saw the saw the idea.

21:24 Brad: Well, it's interesting you say that.

21:26 So the company I'm at now has this.

21:29 like whole product there's a documented product development process it's all these phases starting from way way upstream of like idea generation right and then there's like this one it's like imagine a flow chart there's one section in the flow chart it just says like development happens right and then it's

21:45 Scott: Magic

21:46 Brad: and

21:46 Scott: happens.

21:46 Brad: magic happens and then you know data is is expelled from that and we evaluate it and we go back and do our product process again and i i thought that was

21:54 That was funny.

21:55 I was like, oh, the whole part that the engineers think about is the SDLC and to the product managers and just there's one box,

22:01 which is like developers do stuff.

22:03 Scott: Yeah.

22:04 Brad: So but I think your question is like,

22:06 how far upstream should the SDLC go?

22:09 Here,

22:09 here's my thought about that.

22:10 Pretty far.

22:12 Because I think it should include that product part,

22:14 personally.

22:15 See,

22:16 I guess there's a few different purposes for the SDLCs, right?

22:19 One is like

22:21 How do we as a software team just operate efficiently effectively,

22:25 which I think is different than the compliance purpose,

22:28 which is how do we know that the software is doing the thing that the business wanted to do,

22:33 right,

22:33 which is kind of a different purpose.

22:35 You

22:35 Scott: Yeah,

22:36 Brad: know,

22:36 Scott: the yeah

22:36 Brad: Venn diagram is very highly overlapped, right?

22:40 But to me, and I think about it more from the how do we know that we're.

22:46 doing the best we can do and from that regard I think including further upstream steps is good like getting into that product management space right of like hey well they collect ideas and then they evaluate ideas with finance and stakeholders and customers and then they probably all those steps I think is good to write down too because I think it's good to show

23:12 well with to ourselves but also outside the team like you know this is this is how it gets done this is how it gets done i used to give this talk yeah i haven't done it in a while but when i was at rover and um i would do it as part of the the new employee onboarding in a couple of years a couple of times per year at the like an all hands which is like you know

23:33 how do you talk to the engineering team not like you know what do you say like and there were just three ways it's like do you need help with the software you do use to do your job you go talk to the IT team and here's how you interface with the IT team you can go into on the way to help this system or you can go into the slack channel or whatever do you

23:53 Is there a problem with the software that works that's out there currently and you need to tell someone about it? Like here's the avenue that you go to tell someone about it and it can get flows through to the person who can fix it.

24:03 Or do you have an idea for how to make it better?

24:07 And then here's the other channel where you go submit that idea.

24:09 In theory, sort of each of those, those are the three, I was like, there's only three doors to technology at this company.

24:16 And these are the three. And.

24:19 in theory each of those kind of has their own little sdlc so to speak which is like okay someone comes along and says i see a problem with the software right what do i what are the steps that they follow right

24:29 Scott: Yeah.

24:29 Brad: where's the button they push if they think it's emergency or where's the you know ticket they submit if they think it's not an emergency or whatever and um you know that third one i mentioned which is i have an idea for how to make it better for our customers it's just the beginning of that sdlc someone has an idea

24:46 has an idea what happens with it goes into a bucket project management project management does whatever they do thinks about it right they

24:55 Scott: Yeah.

24:55 Brad: make a you know i think it's i think it's useful to go way upstream even in a lightweight way um it might be in a small company you know if it's just you and me two people it might be you have an idea put a sticky note on the wall

25:09 Scott: Yeah.

25:09 Brad: Right.

25:10 That's step one.

25:10 Scott: Well,

25:11 and one of the things that we would want out of that, like let's we if we just take our let's just take our T.O. part of our CTO hat off and put our C part on.

25:21 Right.

25:21 Brad: Yeah.

25:21 Scott: Which is we're we're like a chief. We're steward to the business.

25:25 Right. Like a big piece of being a steward to the business is.

25:29 How do we know that the investments we're making are worthwhile investments,

25:32 right?

25:32 Brad: Yeah, for

25:33 Scott: So

25:33 Brad: sure.

25:34 Scott: the further, if you only do, if you only sort of think about the process of writing code, but you don't think about the process of what comes into the request bucket,

25:43 right?

25:43 Brad: Right.

25:43 Scott: And you don't have some, you don't have some thoughtful, systematic way of evaluating those ideas,

25:49 right?

25:51 Brad: Yeah,

25:51 Scott: Then

25:51 Brad: that's

25:51 Scott: that's

25:51 Brad: a.

25:52 Scott: probably a road to wasted money.

25:55 Brad: Absolutely.

25:56 And that's more of a typical product management type of function. But even within engineering, we have engineering driven investments that you want to do that as well.

26:04 I think that's critical.

26:05 In fact, I would actually say from a business perspective.

26:10 It's interesting. So often in our careers, I'm interrupting myself,

26:14 I'm sidebarring myself.

26:15 So often in our careers, at least in my career,

26:18 I have CEOs who say, you know, hire more engineers.

26:22 Do you need more engineers? How can you go faster?

26:24 And when I say sometimes,

26:26 and I say it more politely than this.

26:30 Well, why don't we just pick better stuff to work on?

26:33 Scott: Right,

26:33 right, right.

26:35 Brad: Like it's going

26:35 Scott: We've talked about that. If all of a sudden we're way more efficient as engineers,

26:38 that doesn't necessarily mean we get more value done.

26:41 It might be we're just getting more things that aren't that valuable done.

26:44 Brad: nowhere fast.

26:45 Yeah.

26:46 So like I learned that from my experience, actually the head of product management when I was at Rover was a really big believer in that. Like, hey, let's.

26:56 you know the classic ready shoot aim he was a really big like no no let's aim ready let's really think about where we're going to aim and then when we aim like we're going to pull the trigger hard and blast it we're going to really think this through and I admired that in his his thoughtfulness up front um his his he had a lot of really positive things to to contribute to like my experience but um

27:23 I think

27:23 Scott: I

27:23 Brad: that's

27:23 Scott: have

27:23 Brad: a good thread.

27:24 Scott: I have two like pieces of this that I want to pull on different threads on and maybe you can tell me which one is more interesting or which one we should do first. So one really simple thing is you and I are talking about this SDLC or how software gets done as if it's just like, well, obviously we know how to do it. We've been doing it for 30 years. Right.

27:43 But what are the.

27:44 bare minimum or what are the what are the what are the typical stops along the way like what are the typical features we would expect to see in a basic SDLC

27:56 Brad: It's a great question.

27:58 I would think the bare bones minimum.

28:01 I haven't thought about this before.

28:03 This is a really good question.

28:04 I would think the absolute bare bones minimum are the following two things.

28:11 where is code stored and how is code deployed or built and deployed if it has to get built um because ultimately like you can't have everybody with their own the same you know different copies of the code we've lived in i don't know i've lived in those days that's craziness

28:33 Scott: Yes

28:35 Brad: And

28:35 Scott: Yeah,

28:36 and then you can use the version control.

28:37 Brad: totally where version control is a folder on the production server and everybody goes and makes a copy of it.

28:44 Scott: Yep.

28:44 Brad: Someone changed the sim link and that's the new version.

28:49 Scott: Hey, blue green,

28:50 baby.

28:52 Brad: So think, hey, we all agree,

28:54 like here's the repo.

28:58 And maybe I guess part of that has to be on sort of what your kind of like branching strategy is.

29:04 But I don't think that's too hard.

29:05 I mean, there's, you know, there's known patterns out there. You can just say, look, we follow this strategy.

29:10 But you've got to have one. You can't have one person having a mainline and branching off of it, another person making release branches and deploying.

29:15 You have to have one way you store code and one way you deploy code.

29:19 Scott: Okay, hold on a second, though. I like this. I like where you started.

29:23 If you start with the

29:24 um we could start with the end in mind right how is the thing that the customer is using how did it get into their hands that's deploy so how do we deploy this thing okay and then if you're going to answer the question how do we deploy this thing we got to have an answer of where did it come from where was where did where did we store the thing that got deployed right the source

29:47 Brad: And there's a piece in there between which is maybe the build piece,

29:51 right?

29:52 Scott: So

29:52 Brad: Yeah,

29:52 Scott: how

29:53 Brad: where did it come from?

29:53 Scott: do we deploy it? Where was the source code stored?

29:56 And we just inserted a new step called the build process.

30:00 Brad: Yeah,

30:01 which is like, what is it?

30:03 Scott: Yeah. Okay.

30:04 Now,

30:04 if we only have those three things,

30:06 I don't think we have a very interesting software business.

30:09 And the reason I say that is because you haven't yet talked about how we change it.

30:14 Because it feels like

30:14 Brad: Yeah,

30:15 Scott: how we change it is going to be the very next thing we need to answer

30:18 Brad: sure.

30:19 Scott: the question of.

30:19 Brad: Sure.

30:20 So then the other next is how you change it.

30:22 What are your processes for changing?

30:24 I had this, I can't remember the saying rats.

30:28 I have a sticky note with it on it. But like,

30:30 you know, if I'm doing something new from scratch all the way a production thing,

30:35 I try to just like get the hello world app.

30:38 all the way to production first because then there and out it's easy you're just making updates right

30:44 Scott: Yeah.

30:44 Brad: they're big updates because it just it's right but I've seen this thing where you like somebody builds a whole bunch and they're like ready to go and then it's like oh well now there's this all of this work you got to do to go from it's in wherever you store it to like making it live and that's pretty heavy lifting and if you do that up front it's often lighter weight

31:04 But

31:04 Scott: Yeah,

31:05 Brad: your point

31:05 Scott: totally.

31:05 Brad: is, I only bring that up from the,

31:07 yeah,

31:08 how do you change it? Once you've got it somewhere,

31:10 how do you start changing it?

31:11 Scott: How do you change it? Right.

31:12 And that might be that's where we then start to peel that onion and we get the answer we get, you know, deeper. The next layer of those questions are,

31:20 well.

31:21 You know, how do you change it? Probably the answer is there's a version control system somewhere and we're checking into version control.

31:27 Brad: And

31:27 Scott: How

31:28 Brad: what is

31:28 Scott: do

31:28 Brad: it?

31:28 Scott: you how do you validate that you want the change before you really commit to the change? And so that's a that's part of the how do you change it? Right.

31:39 But it starts to really pull on different questions around maturity, which I think are well.

31:47 How do you test it?

31:50 How do you audit it before,

31:53 you know, how do you audit it from a code quality perspective,

31:56 right?

31:56 These are sort of the things,

31:59 the questions that get inspired by the,

32:03 now we're talking about how we change it.

32:05 Scott,

32:06 you and I are going to have little two guys in a garage. How are we going to change this?

32:09 And we might say, you know what? We've both been doing this so long. We both trust each other.

32:13 Like our answer to how we change it is.

32:17 change it brad if you want to change it you change it scott you change it if you want to change it and uh we just we we speak in an unspoken language of trust that we know that we're all right in the right in the like you could write it and i could write it and it would feel like it came from the same brain right

32:33 Brad: So there's a piece in here, I'm not sure where it fits in this part of the kind of the life cycle, but I think about it.

32:41 from a operational point of view which is like if something is broken and I go look at the last commit for the last deploy I want to know what was in that deploy of course I can look at the code and I can see but I would really like for there to be a description somewhere

33:03 either

33:03 Scott: Yeah.

33:03 Brad: a change log or someone said this is what I'm trying to do here it can be in the pull request it can be in a ticket that the pull request references but I've always found that a really really useful piece of like

33:21 Hey, it's 6.30 p.m. on Friday and everything broke.

33:27 Yep. What was the last thing to change and what were they thinking,

33:30 right?

33:31 Scott: Yeah, you know, it's so interesting.

33:33 A little side note on that.

33:38 One of my newest one of my newest.

33:42 First of all,

33:42 I agree with everything you just said about like, what is what is the change that was made?

33:47 And I think that I've been a big believer, you know, GitHub and pull requests into,

33:51 you know, whether your developer branch, your main line,

33:53 whatever that might be, that's like kind of been the regime that I've lived in for the last, you know, at least 15 years,

34:00 Brad: Mm

34:00 Scott: it

34:00 Brad: -hmm.

34:00 Scott: wasn't always GitHub,

34:01 but it was like Git and things like that.

34:04 So, you know, kind of the the notion of the

34:07 commit log and the and the pull request like i've always been pretty adamant that the at the very minimum the thing that got merged into the the main develop branch whether it was main or whether it was developed but the thing that went from the developer into the group the group version of the code that had better have a high quality description attached to it

34:27 Brad: Yeah.

34:28 Scott: right

34:28 Brad: Or referencing that description for sure.

34:30 Scott: yeah

34:31 Brad: And that's coming back to something we talked about earlier. That's what auditors want.

34:34 There's one what was this change?

34:36 Why was it there?

34:37 Scott: Yeah. What's interesting is, and I'll admit this is a little bit of like personal growth.

34:43 It drives me crazy when I see individual get commits that are things like, try this,

34:53 that didn't work,

34:55 try again,

34:56 right?

34:57 That drives me crazy.

35:00 And what's really interesting is I have found that the AI coding agents now,

35:06 if I've been working,

35:08 even if I'm the one writing the code, I'm just writing code or I'm having the agent write code.

35:12 When I tell the agent time to commit this,

35:16 this is a good checkpoint,

35:18 commit it.

35:19 Man,

35:20 they write really good commit messages.

35:22 Brad: Oh, yeah.

35:24 Scott: And I'm like, all right, like I would have never written that,

35:27 but they wrote it and it'll it'll come in handy if I ever come back and look at this in the future.

35:33 Brad: Yes, yes.

35:35 Okay, so that reminds me of something because I was doing it the other day on something I was working on, which is version numbers.

35:42 Scott: Yeah.

35:43 Brad: And how that plays into the SDL. So,

35:45 you know, I guess we have hashes on a PR.

35:48 A lot of times deploys get a hash somehow associated to it.

35:52 Um,

35:52 but versions

35:53 Scott: I

35:53 Brad: are kind

35:53 Scott: think it depends on the scale of your project, but

35:55 Brad: yeah,

35:56 Scott: I

35:56 Brad: it kind of depends.

35:56 Scott: know recently, not recently, but within the last, you know, year or so at, you know, the one of the companies that I work with, we basically adopted a SEMVER,

36:09 semantic versioning. So basically all of our components have a, you know, major dot minor dot.

36:16 um sub uh classification to them and you can't change the you can't change the semantic meaning of the api with a minor version if you're going to change the semantic meaning you have to you have to you have to bump the version and you have to we agreed to support the old version and so that significantly changed that was a great example of a sdlc thing right so we had a

36:40 You know, we changed one, you know, the back end changed something and then the front end didn't know about it and boom,

36:45 some bug got introduced and everyone's like,

36:47 wait.

36:48 This code is not expecting that behavior,

36:49 right?

36:50 Oh,

36:51 okay. Well, let's agree that we don't change the semantic meaning of stuff unless we support the old version and have a new version and give some kind of a – and that bug happened,

37:02 retrospective, figure out what happened. Oh,

37:05 let's make a decision about how we change things absolutely turned into a new way of working.

37:13 That has I think in the ultimately it's made us go faster.

37:19 Right.

37:20 But there's tradeoffs with it. And I think that's kind of an interesting aspect of how SDLCs need to evolve as you learn things.

37:30 Brad: Yeah, I think I mentioned this earlier to me like

37:34 after sort of the sort of foundational just nuts and bolts like we were talking a minute ago it sort of becomes just a repository for all the things you learned in retrospectives where you say oh let's not do that again right and often you just say you say that but an sdlc gives a written document gives you a place to like actually put it and say like oh if we increment the version this is what we do whatever or we don't

38:00 Scott: Yeah.

38:00 Brad: increment the version unless we

38:01 Unless we do the river.

38:02 Sidebar,

38:03 Scott: Yeah.

38:03 Brad: I have a question for you.

38:04 I think I've made this mistake several times.

38:08 It always seems like versioning is one of those things where you never do it early because you just don't. But then you get a little ways along and it sure would be nice to have it.

38:22 And it's probably one of those things that's worth just kind of like putting in a little extra effort up front to have it because if you ever have any success and ever grow to any number of people,

38:34 it'd be handy.

38:36 Scott: Yeah.

38:37 You know, it's interesting.

38:38 So I want to I feel like we haven't totally pulled on the thread of the what are the kind of building blocks

38:45 Brad: No,

38:45 Scott: for.

38:46 Brad: we haven't.

38:47 Scott: But I will say that this is a little bit of a story of like get stuff in early.

38:54 I have really become now just all my individual personal projects that I have,

39:00 you know, I I'm.

39:04 really loving the idea of right from day one especially now that i have ai code eight coding agents write so much of the the boilerplate for me it's like from day one it's like yeah i've got a cicd that works with it when i you know i've got a develop branch and a main branch and when i merge when i open a pull request boom i get an ephemeral environment up and running that i can play with my play with the latest version and i and i've got you know

39:29 automated end-to-end tests and automated unit tests and every time i ask the agent to write me anything i tell it you must make sure the unit tests have 100 test coverage and

39:39 Brad: Yeah.

39:39 Scott: it must be linted and so like these notions of like lint end-to-end unit tests or unit tests that have coverage end-to-end tests using cypress or play right or something like that and then just having like

39:54 No change to the code can happen unless all those things pass.

39:59 Brad: And even with it's just be me and my friends Claude and ChatGPT writing code on these projects,

40:07 I like having those guardrails.

40:13 Scott: Yeah.

40:14 So a little while back, we recorded an episode about QA.

40:19 Brad: Yeah,

40:19 yeah,

40:19 Scott: And we talked about, you know,

40:21 I talked, I remember I was saying about how that to me, QA begins way upstream with like,

40:27 do

40:28 Brad: yeah

40:28 Scott: you have accurate requirements,

40:29 right?

40:30 And so all those steps in that process, do you have accurate requirements?

40:34 Did you write a technical design doc?

40:36 Was there a code review?

40:38 Was there test automation?

40:39 All these different, all these different steps along the way. Was there monitoring on this, all these kinds of things?

40:44 all these steps along the way that ultimately lead to quality to me as you get as you make the SDLC more robust those are all parts that just go into the SDLC and what you're kind of saying is well now the robots do a lot of those parts which is pretty cool

41:00 but I

41:01 Brad: But

41:01 Scott: think it's

41:01 Brad: I feel like I still want them to have the SDLC governing them.

41:06 Scott: yeah for sure but I think I think all that's part of it I think to me if you're going to purely go just from the engineering point of view I would say the SDLC starts with a written design doc

41:22 Someone's asked you to do something,

41:24 they've communicated it to you somehow that they want you to change the system.

41:28 Maybe they wrote you a document,

41:30 maybe they whispered something in your ear,

41:32 who knows.

41:33 Step one, you write down how you're going to do it.

41:38 Brad: Okay, so I love that idea.

41:40 But I feel like I want to challenge you and say, I think there's a step before that, that I think maybe even more important.

41:50 And that is, do you have, have you described the feature correctly?

41:56 So in other words, not the how I'm going to code it,

41:59 but the what is it that I'm building?

42:01 And I say this only because I was working with this team recently where I.

42:09 they you know they came in they asked me to do a code audit i did a code audit and i was like oh the code's in really good shape um i but i then went and said where are all your artifacts that describe this code like where are your feature briefs or what is the you know what and i found that like that's they didn't have anything it was very much a uh you know like the the product owner was very much like a

42:32 in a live meeting and describe it to the engineers and then the engineers would build something and like the capturing of that was like not was nowhere and

42:39 Scott: I have bad news to report.

42:42 Brad: yeah

42:43 Scott: We are in violent agreement.

42:48 Brad: i wanted to fight over this

42:51 Yeah,

42:51 Scott: Yeah.

42:52 Brad: so it's interesting because what's interesting is then when I worked with that team, I was like,

42:56 hey,

42:56 you need to start writing these feature briefs. And I took a little bit of time and wrote some feature briefs for the based on what the product owner wanted.

43:03 And the development team's reaction to this was,

43:06 oh, my God,

43:07 this is amazing. We've never had this.

43:09 This makes our job so much easier.

43:13 Scott: Absolutely. So a minute ago, I said, if you're looking at it purely from the engineering point of view, you'd start at technical

43:20 Brad: That's

43:20 Scott: design docs.

43:20 Brad: the phrase I missed.

43:21 Scott: But if you really start the whole thing, I think it starts with just a project charter,

43:26 a one pager,

43:27 you know, maybe you could do two pages, but that's the maximum of just like, just give me an outline.

43:33 What is the problem?

43:34 What's the high level solution?

43:36 What are you trying to do here? Right?

43:39 A user story, right?

43:40 What could be as simple as user story,

43:42 right?

43:43 As a client, I want to be able to cancel my order so that I don't get the thing I bought, right?

43:51 Brad: Yep.

43:51 Scott: And it has to start there.

43:55 And then it goes through depending on the scope of it.

44:00 maybe a functional specification maybe wireframes or high fidelity designs maybe interactive designs you know someone made something with figma maybe they made something with maybe they vibe coded something with lovable or something like that that actually shows

44:14 Brad: Yeah, yeah

44:15 Scott: the engineer here's how see how I really want it to work it doesn't do anything but I wanted to interact this way

44:22 Yeah, all that feeds up to now the engineer says,

44:25 okay, you've told me what you want.

44:27 I'm going to write a document that I refer to as either,

44:30 I like to call it an implementation plan.

44:33 Here's

44:33 Brad: Yeah,

44:33 Scott: how I'm going to make

44:33 Brad: yeah.

44:34 Scott: that come to life.

44:35 You know, the company I'm at now, they call them technical design docs. I've heard them called all sorts of things, right?

44:39 But I like the implementation plan. Okay,

44:41 you told me what you want.

44:43 I'm going to tell you how I'm going to make it.

44:46 Right. Well,

44:46 Brad: Well,

44:46 Scott: yeah,

44:46 Brad: you know, what's funny is that's what I've also I'm more and more adamant that I have to I tell my AI coding agents,

44:52 don't write any code before you write any code. Tell me what your plan is. Give me your implementation plan.

44:57 Scott: absolutely.

44:59 Brad: Yeah.

45:00 Scott: And you said that to me,

45:03 I've experienced that, we've had people on this show who said that's the way to do it.

45:08 And we've talked earlier,

45:09 I don't know what episode it was, but about how, look, AI can only do these like five minute tasks,

45:14 right?

45:15 So you got to get the implementation broken down into little pieces.

45:19 Yeah, to me, the SDLC starts way up there.

45:21 Somebody has a user story.

45:24 I really

45:24 Brad: Yeah.

45:24 Scott: have an ethic.

45:26 I want to be able,

45:27 as a business,

45:30 I want to sell widgets so that I can make money.

45:34 Brad: It's interesting,

45:35 too,

45:35 because I think that like I haven't played around with this yet myself,

45:40 but I feel like.

45:44 An experiment that I'm interested in trying out, I don't do this for my own projects like I don't have, you know, JIRA or Trello or using GitHub issues I don't like create a bunch of to do's and then have them sitting there ready for me to check off the to do's tend to be in my brain,

46:02 you know.

46:03 But I think more and more, if we think about this from a, so again,

46:08 I just feel like there's this whole like confluence of events of like,

46:12 what does it mean to build software well?

46:16 And now we have this notion of we have all of these, you know.

46:21 We have whether we're hiring real human beings to do it or whether we're using AI coding agents or we hire real human beings that use AI coding agents,

46:30 right?

46:31 Like I'm more convinced than ever that the notion of what are the building blocks necessary to build software well,

46:39 right? Whether that be high quality.

46:44 feature descriptions into high quality implementation plans into high quality code into high quality testing into a high quality you know CICD process you know whatever that whole pipeline right there I think it's more and more important whether they're flesh and blood engineers or silicon engineers doing these things

47:08 Scott: Yeah, especially that upfront stuff.

47:12 Brad: Yeah,

47:12 Scott: That

47:12 Brad: and so

47:12 Scott: upfront

47:13 Brad: then that makes me,

47:13 Scott: stuff

47:13 Brad: that

47:13 Scott: saves

47:14 Brad: makes.

47:14 Scott: so much pain downstream.

47:16 Brad: Yeah.

47:16 So that's the experiment I haven't done yet, which I think maybe that's the next thing I need to do in sharpening my own saw or sharpening my own axes, you know, set up my own personal Jira or my own personal GitHub issues and start writing out my tickets and

47:33 Scott: Okay,

47:33 Brad: start there.

47:34 Scott: I have three thoughts for you. I'm going to just say words so I don't forget them all. They're square,

47:38 circle,

47:39 and gherkin.

47:41 Let me come back to all those.

47:42 Brad: Okay.

47:43 Scott: My colleague,

47:44 Johan Heller, gave a great presentation once to some product managers about the importance of requirements.

47:51 And he said,

47:51 look,

47:52 if you give me a requirement that says you want a square,

47:56 what do you want exactly?

47:58 And he put up on he had one slide and it was a.

48:01 geometric square it's like do you want this and then he had another slide which was like you know the square cash register thing that they've got you know coffee shops and stuff or did you want one of these or then the next slide he put up was you know like one of the in carpentry there's like it's actually triangle shaped but they call it a square and and

48:17 Brad: Right, right

48:18 Scott: he put or did you want one of these like all of those are squares right so like which square did you want and if you just say you want a square and aren't more descriptive than that

48:28 I, well,

48:30 there's a two out of three chance I'm going to build you the wrong one, right?

48:33 Brad: Yep.

48:33 Scott: So requirements are really important.

48:37 Circles, you just mentioned the word pipeline, and we sort of talk about this in very waterfall-y way,

48:45 but each of these steps actually is a bunch of kind of loops that go around and round,

48:51 and people...

48:54 are often uncomfortable with that and it's just like look keep on going around on this spec till you get it right keep on going around on this tdd until you get it right keep on we go around on the code until we get it right we don't just write the code once and say well it's done i'm going to commit it and it's all buggy and stuff no we keep on going around around so it's hard when people want to write this write these documents and have this mindset that we're doing all these stages and going from one to the other but actually

49:20 Each stage is a loop,

49:22 and sometimes it's actually a loop.

49:24 back to the previous stage.

49:25 That's fundamentally agile scrum, right? Which is like, we're

49:28 Brad: Yep.

49:29 Scott: going to put this in front of the customer and they're going to say,

49:31 oh no,

49:32 no,

49:32 that's not what I really wanted.

49:33 And we're going to go back to the beginning.

49:34 And that's very hard to write in a document when we use, you know, words and bullet points and indentation and, you know, you know, what's the, you know, the, when,

49:44 what do you call the, the not bullet points when you have the letters and numbers,

49:47 what's that called? An outline.

49:48 I don't know.

49:50 You have an outline.

49:52 It's very hard for us to capture that in writing.

49:56 Brad: Yeah.

49:56 Scott: Right.

49:57 But it's really the key to the successful thing.

49:59 And the last thing I said was Gherkin.

50:01 I'm not super familiar with this. I've never actually personally used it. But there's this framework.

50:06 I think it's called the Gherkin framework for writing requirements.

50:10 And I once worked at a company where we had this contractor who wrote this thing.

50:16 So that a product manager could put requirements using this Gherkin framework right into a ticket and it would read from the it would read from the Jira ticket and change the code.

50:26 And I was like,

50:27 whoa,

50:27 well, that's cool,

50:29 but we're not there yet.

50:31 Right.

50:31 Brad: Right.

50:31 Scott: But now with with AI and vibe coding,

50:37 we might be getting a lot closer.

50:40 Brad: Yeah, yeah,

50:40 Scott: Especially

50:41 Brad: curtain.

50:41 Scott: if those requirements can have acceptance criteria and all those kinds of things.

50:47 Brad: Yeah, yeah.

50:48 Okay,

50:49 so here's the other topic that I was wanting to pick your brain about. And I always ask this whenever we talk about one of these best practices or like whenever we talk about these notions of like.

51:03 You know, systems for improving software productivity or development.

51:10 I always like to ask the question,

51:12 well, what are the unintended consequences? What are the what are the potentially toxic side effects that can come from this?

51:18 And I.

51:21 I believe I have seen in practice,

51:24 and I think that it's explainable that this can happen, that some teams can just get overly literal or overly focused on the rules of the software development lifecycle and

51:40 Scott: Mm-hmm. Mm-hmm.

51:41 Brad: sort of weaponize them against each other.

51:46 Scott: Yeah.

51:47 Brad: And I'm just curious what your experience on that is or what you think about other

51:52 Scott: I haven't

51:52 Brad: than the human nature of it.

51:54 What do we do to prevent that?

51:56 Scott: had that experience of weaponizing, but I've had the other experience of like software engineers,

52:04 look, we write code and code has to be precise,

52:07 right? It has to do exactly what it has to.

52:13 There's not ambiguity when the code's written. It does a thing, one thing or the other.

52:17 And sometimes software engineers want their SDLC to like be equally as precise and there's going to be gray areas.

52:25 I see this also just tangentially related to like career leveling guides,

52:30 right?

52:30 These software

52:31 Brad: For

52:31 Scott: engineers,

52:31 Brad: sure.

52:31 Scott: they want like everything specified for how they get promoted to the next level.

52:35 And it's like, well, look, we can't write every single thing down.

52:40 with how we make software.

52:42 There is, if you follow these steps from software,

52:45 it's not going to come out right.

52:46 You still have to use your brain and you still

52:49 Brad: Right.

52:49 Scott: have to collaborate with your peers and have conversations and think a little bit, right?

52:54 So to me, that's more of the pitfall, which is people want to go to such a level of specificity and get every single thing done. And well,

53:03 if so-and-so does this and then...

53:05 they want to every single step as opposed to saying there will be a code review they want to say this is exactly how the code review will happen and this person rejects it and then they do this and if they or they accept it and they do this and they have 48 hours to do this and so on and so forth it's like at some point you just have to you can't actually prescribe every single step of what we do

53:27 Brad: Yeah,

53:28 that's like the conversation around like we can't take everything literally,

53:32 right?

53:32 Scott: Yeah.

53:33 And I see engineers getting wound up. They want, it's just their nature,

53:37 they want to figure out every detail.

53:40 Brad: Yeah,

53:40 Scott: And I think that's probably, if you're going that way, you're kind of missing the spirit of it.

53:46 Brad: yeah,

53:46 I think that's that seems certainly true. And I think that the

53:51 One of the things I've noticed in some organizations where they maybe it's because they get big,

53:58 maybe it's because of cultural tensions or things like that, that they they feel they gravitate towards notions of like of like accountability matrices,

54:14 matrices,

54:15 right? Like,

54:16 well.

54:18 i'm you know i don't know this is like this is a made-up example but like well i can't fix that bug because the software development life cycle says that the product team has to prioritize the bug and they get together once a month but they haven't been meeting and they haven't been prioritizing they haven't been tagging any bugs as as

54:40 Scott: Mm

54:40 Brad: to fix so that's why i'm not fixing that bug because this the stlc says i

54:46 I'm not supposed to do that,

54:48 Scott: Yeah,

54:48 Brad: right?

54:48 Scott: we're just talking Dilbert at that point, right?

54:52 Brad: Yeah.

54:52 Scott: there's this Dilbert I can't remember Dilbert's buddy not not Aesok the intern but the other one who was really a rotten guy and he says um you know he's asked for oh Wally that was his name Wally and he's in the status meeting and he says you know the weekly Wally report is bristling with tales of success and he says you know I gave so-and-so inaccurate estimates because they didn't give me a good spec and I gave

55:18 gave you know i submitted this bug because i didn't have time to do it right and so and so forth and the pointy haired boss gets really mad like how could you call any of that success and he said well i don't have any written objectives to compare them to and so it's kind of the same idea like you know if you get in these dilbert worlds where people are just so either blindly following the rules or if there's no rules and they're just doing ridiculous stuff again it comes

55:44 It comes back to the same thing at a certain point, you have to be a team,

55:47 right?

55:47 Yes, you have to be

55:48 Brad: Yeah.

55:48 Scott: a living,

55:49 breathing,

55:50 collaborating.

55:52 We're in this together to make software. I've said this probably on this podcast,

55:57 software is a team sport,

55:58 right? It takes a village and there's a certain quality,

56:04 qualitative aspect of community and teams that you can't codify.

56:09 Brad: Yeah.

56:10 Yeah.

56:11 I agree with that. That seems true.

56:16 Scott: It's kind of the most, the team part's kind of the most fun part of software.

56:20 Maybe.

56:21 Brad: Totally.

56:22 Scott: I mean, getting to see it work is fun too.

56:26 Brad: Yeah,

56:26 I mean, I'll, yeah,

56:27 I think so. I mean, I know that in my career, the thing that gives me the most joy is.

56:36 that we built it together right like you can look across the table at the people that you built the thing with and yeah you built it that's cool but

56:46 Scott: yeah

56:46 Brad: it's also cool that you built it together yeah

56:48 Scott: we did it together we did

56:49 Brad: yeah

56:49 Scott: this I

56:50 Brad: i

56:51 Scott: feel like that's a great spot to stop we

56:54 Brad: agree that sounds like the right ending

56:57 Scott: did it together

56:58 Brad: We did it together. Awesome.

56:59 Scott: All right. Well,

57:00 ladies and gentlemen out there in CTO land,

57:04 remember to tell all your friends to smash that subscribe button to rate and review.

57:09 And we'll see you here next week. Is that right,

57:12 Brad?

57:12 Brad: Yeah,

57:12 absolutely.

57:13 Scott: All right. Have a good one, everybody.

57:15 Brad: This episode of How Many CTOs Does It Take Podcast was edited by Saffron Epigow.

57:20 Our theme song was AI generated by Brad.

57:23 Please follow us on all the social media platforms at at how many CTOs pod you can find us on YouTube LinkedIn Instagram Facebook threads X TikTok and patreon or at our website at how many CTOs pod calm and remember to rate review and subscribe on the podcast platform of your choice thanks for listening