Transcript: 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 Scott 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 Scott So the most important question of the day is,
1:01 Scott have you listened yet to the new Taylor Swift album?
1:07 Brad I have not.
1:09 Brad 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 Brad 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 Brad And then the opening bands are always a nice little surprise because you.
1:34 Brad Because you see you go there for the headliner, but you see an opening band you're like, oh shit,
1:38 Brad they're pretty good, too
1:39 Scott A hundred percent.
1:41 Scott I got a lot of questions for you in my music festival going days,
1:44 Scott I always like to go early in the day when it's not crowded,
1:47 Scott 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 Scott So I'm curious to know what you're listening to that you like right now.
1:56 Scott And I'm sure all of our tech loving nerds out there kind of know about this too.
2:01 Scott 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 Brad I went to go see last week I saw a really fun band,
2:13 Brad 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 Brad And I got to see them live. I actually went to that show with my youngest.
2:31 Brad 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 Scott 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 Scott 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 Scott 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 Brad They had an opener,
3:18 Brad 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 Brad 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 Brad but I've gone to at least three Who concerts that were their last tour ever,
3:38 Brad 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 Brad exactly. It was the one with the clash.
3:58 Brad 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 Brad 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 Brad 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 Scott I was in California last weekend and saw three shows at the Hollywood Bowl.
5:03 Scott I had never been to the Hollywood Bowl before.
5:08 Scott The sound was excellent.
5:09 Scott I saw two nights of LCD sound system.
5:13 Brad Oh,
5:14 Scott which
5:14 Brad yeah,
5:14 Brad 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 Brad 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 Scott 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 Scott I think to be a Swifty,
5:43 Scott you've got to know the lyrics to all the songs.
5:45 Scott I don't really know that,
5:46 Scott but I'm a fan of Taylor Swift.
5:48 Scott I am impressed with her as a musician and an artist and overall just a.
5:56 Scott 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 Brad I think she's amazing.
6:07 Brad She's incredibly smart and deliberate in her creativity.
6:13 Brad So that part,
6:14 Brad I'm.
6:16 Brad 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 Scott I went to see the Eras
6:27 Brad Oh,
6:27 Scott tour.
6:27 Brad wow.
6:29 Scott Yeah,
6:29 Scott 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 Scott And I was blown away.
6:41 Scott And I'll tell you, I was blown away by a few things.
6:43 Scott The fans are just out of this world.
6:45 Scott She has such an amazing relationship with her fans and super positive.
6:52 Scott It was a giant sing-along. I mean, she could have just got up there and been like,
6:55 Scott okay, we're going to sing this one now,
6:57 Scott everybody.
6:57 Scott 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 Brad 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 Scott They were the opener for LCD Sound System.
7:47 Scott We were walking in towards the end of after their set was over the first night.
7:52 Scott 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 Scott And I guess this is a band,
8:02 Scott 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 Scott 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 Scott the music section.
8:13 Scott 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 Scott party in the back. So we got business to talk about.
8:32 Scott And today,
8:33 Scott I think our topic is the SDLC,
8:36 Scott the software development life cycle.
8:38 Scott And I think specifically what you told me you were interested in discussing was the documented SDLC,
8:46 Scott the thing that's written down.
8:48 Brad Yeah, I mean, presumably,
8:50 Brad 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 Brad I've worked with ventures of all different sizes,
9:08 Brad right,
9:09 Brad from,
9:10 Brad I mean, I guess I haven't, I mean, the largest,
9:12 Brad 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 Brad But, you know, everything from two guys in a garage to, you know, 2000.
9:27 Brad And I think it's interesting that.
9:29 Brad 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 Brad 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 Scott maybe.
10:17 Scott 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 Brad Totally.
10:39 Brad Totally. Well,
10:40 Brad what have you found?
10:41 Scott Well,
10:41 Scott I want to talk about what we experienced at HealthCo.
10:44 Scott I came in there and the SDLC was already in place and it was pretty robust.
10:51 Scott And what I think I appreciated most about it was two parts.
10:56 Scott One was that it was a
11:03 Scott It was like a tool for retrospectives, if that makes sense.
11:07 Scott What I mean is, if something went wrong,
11:10 Scott 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 Scott 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 Scott I appreciated about it.
11:31 Scott There was an owner of the SDLC and,
11:34 Scott you know, there was like a quarterly amendment and update process.
11:38 Scott It was kind of like the Constitution.
11:39 Scott 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 Scott I'm not really sure.
11:50 Scott But and then and then they were sent out and it was updated and it happened every quarter.
11:56 Scott So as we learned during the quarter,
11:58 Scott 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 Scott So that's what I liked about it there,
12:07 Scott I think.
12:08 Scott It existed there for, well, I would imagine it existed there for two reasons.
12:14 Scott One is a compliance reason.
12:16 Scott 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 Scott And then I think the other was they were doing healthcare and the quality was really important for them.
12:28 Scott And so they wanted to have a consistent process.
12:31 Scott And I remember the, I don't remember the exact words, but the preamble.
12:35 Scott 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 Scott It's a creative process.
12:53 Scott 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 Scott And I appreciated that it made that made sense to me.
13:06 Scott So those are all things I appreciated about it there.
13:10 Scott Now you ask when, when should you have one?
13:12 Brad Yeah.
13:13 Scott That's a great question.
13:17 Scott I think that.
13:20 Scott It's probably a good idea to have one under a few circumstances.
13:25 Scott One is if you're hiring pretty rapidly.
13:28 Scott So like as you're bringing more and more people on,
13:31 Scott again,
13:32 Scott it comes back to that repository of working agreements.
13:36 Scott Like so if somebody shows up, they can kind of have an understanding of like,
13:39 Scott this is how we do it here.
13:41 Scott Right.
13:42 Scott 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 Scott 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 Scott hey.
14:07 Scott Hey, gang,
14:08 Scott this is how we're going to do it.
14:09 Scott But you start to get to that 20, 25 number,
14:12 Scott it gets a little trickier to maintain that consistency just verbally,
14:16 Scott 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 Scott 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 Scott 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 Scott 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 Scott So go ask the question.
14:57 Scott So when someone has an idea,
14:58 Scott 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 Scott And then we can go ask the question,
15:07 Scott okay,
15:07 Scott where do different teams do it differently?
15:09 Scott And we want to make it consistent,
15:10 Scott or maybe we don't mind that it's different on different teams.
15:13 Scott What do we want to improve,
15:14 Scott et cetera, et cetera.
15:15 Scott But I think that's where you start is.
15:18 Scott Uh,
15:18 Scott 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 Brad And I think that, you
15:30 Brad 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 Brad I think that.
15:42 Brad 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 Brad Well, actually,
16:10 Brad let me ask a question about this. So I'll make the following statement.
16:14 Brad 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 Brad 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 Brad OK.
16:34 Brad 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 Brad which are somehow jeopardizing.
16:59 Brad Data security.
17:00 Brad 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 Brad you probably might have to have something written down to guard against that.
17:14 Brad to manage data security.
17:17 Scott Yeah.
17:17 Brad So let me ask you that question.
17:19 Brad In a world where it's never been written down as an official software development lifecycle document,
17:28 Brad is there – am I over-subscribing to this SDLC concept?
17:37 Brad 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 Scott Right. And, you know, from the auditor's perspective,
18:03 Scott they're going to want to know, typically,
18:05 Scott they want to know, you know, was this change to the system essentially approved?
18:13 Scott Did some person in authority authorize this change?
18:19 Scott And they just want to have a...
18:23 Scott The words clean my mind is trace log,
18:25 Scott but that's not really what
18:25 Brad A
18:25 Scott they mean.
18:26 Brad paper trail.
18:26 Brad A digital paper trail.
18:27 Scott They want to have some, okay,
18:29 Scott here's a change.
18:31 Scott Show me who made the change. Show me who approved the change.
18:33 Scott Right.
18:35 Scott And your SDLC document would say,
18:37 Scott well,
18:37 Scott this is who approves changes and this is who makes changes.
18:41 Scott And then an auditor would look at that and say, OK,
18:43 Scott well, prove to me this happened.
18:45 Scott And,
18:45 Brad Yep.
18:46 Scott you know, maybe it's something as simple as,
18:47 Scott 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 Scott 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 Scott well,
19:03 Scott okay,
19:04 Scott how are those, why are those reviewers qualified or, you know, who authorized the reviewers,
19:09 Scott right?
19:11 Scott 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 Scott Maybe you have some criteria,
19:20 Scott but if it's just the two of us and we wanted to be some sort of SDLC compliant,
19:24 Scott you know, or, you know, SOC 2 compliant or whatever all the different frameworks are out there,
19:29 Scott we would just say,
19:30 Scott hey, well,
19:31 Scott 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 Scott but it doesn't matter.
19:50 Brad Yeah
19:50 Scott The detail doesn't matter.
19:51 Scott So they kind of even enforce that in there.
19:53 Scott Yeah, I think that's what the compliance regimes want.
19:56 Scott 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 Brad you know, the classic office space,
20:08 Brad there's pennies going to your account.
20:09 Brad They want to know how that happened.
20:11 Brad And if so-and-so in accounting who's an authorized approver said it was OK,
20:14 Brad then.
20:15 Brad Guess it's okay.
20:17 Scott Right.
20:17 Scott 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 Scott 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 Scott Was the proposal reviewed?
20:50 Scott Did the proposal then have an estimation?
20:52 Scott 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 Scott 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 Scott where does that live in the software development lifecycle at HealthCo?
21:16 Scott 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 Brad So the company I'm at now has this.
21:29 Brad 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 Brad That was funny.
21:55 Brad 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 Brad which is like developers do stuff.
22:03 Scott Yeah.
22:04 Brad So but I think your question is like,
22:06 Brad how far upstream should the SDLC go?
22:09 Brad Here,
22:09 Brad here's my thought about that.
22:10 Brad Pretty far.
22:12 Brad Because I think it should include that product part,
22:14 Brad personally.
22:15 Brad See,
22:16 Brad I guess there's a few different purposes for the SDLCs, right?
22:19 Brad One is like
22:21 Brad How do we as a software team just operate efficiently effectively,
22:25 Brad which I think is different than the compliance purpose,
22:28 Brad which is how do we know that the software is doing the thing that the business wanted to do,
22:33 Brad right,
22:33 Brad which is kind of a different purpose.
22:35 Brad 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 Brad But to me, and I think about it more from the how do we know that we're.
22:46 Brad 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 Brad 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 Brad 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 Brad 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 Brad Or do you have an idea for how to make it better?
24:07 Brad And then here's the other channel where you go submit that idea.
24:09 Brad 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 Brad And these are the three. And.
24:19 Brad 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 Brad 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 Brad That's step one.
25:10 Scott Well,
25:11 Scott 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 Scott 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 Scott Right. Like a big piece of being a steward to the business is.
25:29 Scott How do we know that the investments we're making are worthwhile investments,
25:32 Scott 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 Scott 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 Scott 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 Brad 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 Brad I think that's critical.
26:05 Brad In fact, I would actually say from a business perspective.
26:10 Brad It's interesting. So often in our careers, I'm interrupting myself,
26:14 Brad I'm sidebarring myself.
26:15 Brad So often in our careers, at least in my career,
26:18 Brad I have CEOs who say, you know, hire more engineers.
26:22 Brad Do you need more engineers? How can you go faster?
26:24 Brad And when I say sometimes,
26:26 Brad and I say it more politely than this.
26:30 Brad Well, why don't we just pick better stuff to work on?
26:33 Scott Right,
26:33 Scott 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 Scott that doesn't necessarily mean we get more value done.
26:41 Scott It might be we're just getting more things that aren't that valuable done.
26:44 Brad nowhere fast.
26:45 Brad Yeah.
26:46 Brad 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 Brad 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 Brad 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 Scott But what are the.
27:44 Scott 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 Brad I would think the bare bones minimum.
28:01 Brad I haven't thought about this before.
28:03 Brad This is a really good question.
28:04 Brad I would think the absolute bare bones minimum are the following two things.
28:11 Brad 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 Scott 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 Scott baby.
28:52 Brad So think, hey, we all agree,
28:54 Brad like here's the repo.
28:58 Brad And maybe I guess part of that has to be on sort of what your kind of like branching strategy is.
29:04 Brad But I don't think that's too hard.
29:05 Brad I mean, there's, you know, there's known patterns out there. You can just say, look, we follow this strategy.
29:10 Brad 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 Brad 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 Scott If you start with the
29:24 Scott 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 Brad 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 Scott And we just inserted a new step called the build process.
30:00 Brad Yeah,
30:01 Brad which is like, what is it?
30:03 Scott Yeah. Okay.
30:04 Scott Now,
30:04 Scott if we only have those three things,
30:06 Scott I don't think we have a very interesting software business.
30:09 Scott And the reason I say that is because you haven't yet talked about how we change it.
30:14 Scott 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 Brad So then the other next is how you change it.
30:22 Brad What are your processes for changing?
30:24 Brad I had this, I can't remember the saying rats.
30:28 Brad I have a sticky note with it on it. But like,
30:30 Brad you know, if I'm doing something new from scratch all the way a production thing,
30:35 Brad I try to just like get the hello world app.
30:38 Brad 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 Brad 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 Brad yeah,
31:08 Brad how do you change it? Once you've got it somewhere,
31:10 Brad how do you start changing it?
31:11 Scott How do you change it? Right.
31:12 Scott 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 Scott well.
31:21 Scott 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 Scott But it starts to really pull on different questions around maturity, which I think are well.
31:47 Scott How do you test it?
31:50 Scott How do you audit it before,
31:53 Scott you know, how do you audit it from a code quality perspective,
31:56 Scott right?
31:56 Scott These are sort of the things,
31:59 Scott the questions that get inspired by the,
32:03 Scott now we're talking about how we change it.
32:05 Scott Scott,
32:06 Scott you and I are going to have little two guys in a garage. How are we going to change this?
32:09 Scott And we might say, you know what? We've both been doing this so long. We both trust each other.
32:13 Scott Like our answer to how we change it is.
32:17 Scott 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 Brad 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 Brad 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 Brad Hey, it's 6.30 p.m. on Friday and everything broke.
33:27 Brad Yep. What was the last thing to change and what were they thinking,
33:30 Brad right?
33:31 Scott Yeah, you know, it's so interesting.
33:33 Scott A little side note on that.
33:38 Scott One of my newest one of my newest.
33:42 Scott First of all,
33:42 Scott I agree with everything you just said about like, what is what is the change that was made?
33:47 Scott And I think that I've been a big believer, you know, GitHub and pull requests into,
33:51 Scott you know, whether your developer branch, your main line,
33:53 Scott 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 Scott but it was like Git and things like that.
34:04 Scott So, you know, kind of the the notion of the
34:07 Scott 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 Brad There's one what was this change?
34:36 Brad 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 Scott It drives me crazy when I see individual get commits that are things like, try this,
34:53 Scott that didn't work,
34:55 Scott try again,
34:56 Scott right?
34:57 Scott That drives me crazy.
35:00 Scott And what's really interesting is I have found that the AI coding agents now,
35:06 Scott if I've been working,
35:08 Scott even if I'm the one writing the code, I'm just writing code or I'm having the agent write code.
35:12 Scott When I tell the agent time to commit this,
35:16 Scott this is a good checkpoint,
35:18 Scott commit it.
35:19 Scott Man,
35:20 Scott 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 Scott 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 Brad 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 Brad you know, I guess we have hashes on a PR.
35:48 Brad A lot of times deploys get a hash somehow associated to it.
35:52 Brad Um,
35:52 Brad 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 Scott semantic versioning. So basically all of our components have a, you know, major dot minor dot.
36:16 Scott 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 Scott 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 Scott some bug got introduced and everyone's like,
36:47 Scott wait.
36:48 Scott This code is not expecting that behavior,
36:49 Scott right?
36:50 Scott Oh,
36:51 Scott 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 Scott retrospective, figure out what happened. Oh,
37:05 Scott let's make a decision about how we change things absolutely turned into a new way of working.
37:13 Scott That has I think in the ultimately it's made us go faster.
37:19 Scott Right.
37:20 Scott 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 Brad 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 Brad Unless we do the river.
38:02 Brad Sidebar,
38:03 Scott Yeah.
38:03 Brad I have a question for you.
38:04 Brad I think I've made this mistake several times.
38:08 Brad 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 Brad 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 Brad it'd be handy.
38:36 Scott Yeah.
38:37 Scott You know, it's interesting.
38:38 Scott 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 Scott I have really become now just all my individual personal projects that I have,
39:00 Scott you know, I I'm.
39:04 Scott 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 Scott 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 Scott 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 Brad I like having those guardrails.
40:13 Scott Yeah.
40:14 Scott So a little while back, we recorded an episode about QA.
40:19 Brad Yeah,
40:19 Brad yeah,
40:19 Scott And we talked about, you know,
40:21 Scott I talked, I remember I was saying about how that to me, QA begins way upstream with like,
40:27 Scott do
40:28 Brad yeah
40:28 Scott you have accurate requirements,
40:29 Scott right?
40:30 Scott And so all those steps in that process, do you have accurate requirements?
40:34 Scott Did you write a technical design doc?
40:36 Scott Was there a code review?
40:38 Scott Was there test automation?
40:39 Scott All these different, all these different steps along the way. Was there monitoring on this, all these kinds of things?
40:44 Scott 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 Scott 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 Scott Someone's asked you to do something,
41:24 Scott they've communicated it to you somehow that they want you to change the system.
41:28 Scott Maybe they wrote you a document,
41:30 Scott maybe they whispered something in your ear,
41:32 Scott who knows.
41:33 Scott Step one, you write down how you're going to do it.
41:38 Brad Okay, so I love that idea.
41:40 Brad 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 Brad And that is, do you have, have you described the feature correctly?
41:56 Brad So in other words, not the how I'm going to code it,
41:59 Brad but the what is it that I'm building?
42:01 Brad And I say this only because I was working with this team recently where I.
42:09 Brad 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 Brad 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 Brad 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 Brad hey,
42:56 Brad 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 Brad And the development team's reaction to this was,
43:06 Brad oh, my God,
43:07 Brad this is amazing. We've never had this.
43:09 Brad 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 Scott a one pager,
43:27 Scott you know, maybe you could do two pages, but that's the maximum of just like, just give me an outline.
43:33 Scott What is the problem?
43:34 Scott What's the high level solution?
43:36 Scott What are you trying to do here? Right?
43:39 Scott A user story, right?
43:40 Scott What could be as simple as user story,
43:42 Scott right?
43:43 Scott 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 Scott And then it goes through depending on the scope of it.
44:00 Scott 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 Scott Yeah, all that feeds up to now the engineer says,
44:25 Scott okay, you've told me what you want.
44:27 Scott I'm going to write a document that I refer to as either,
44:30 Scott I like to call it an implementation plan.
44:33 Scott 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 Scott 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 Scott But I like the implementation plan. Okay,
44:41 Scott you told me what you want.
44:43 Scott I'm going to tell you how I'm going to make it.
44:46 Scott 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 Brad 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 Scott I've experienced that, we've had people on this show who said that's the way to do it.
45:08 Scott And we've talked earlier,
45:09 Scott I don't know what episode it was, but about how, look, AI can only do these like five minute tasks,
45:14 Scott right?
45:15 Scott So you got to get the implementation broken down into little pieces.
45:19 Scott Yeah, to me, the SDLC starts way up there.
45:21 Scott Somebody has a user story.
45:24 Scott I really
45:24 Brad Yeah.
45:24 Scott have an ethic.
45:26 Scott I want to be able,
45:27 Scott as a business,
45:30 Scott I want to sell widgets so that I can make money.
45:34 Brad It's interesting,
45:35 Brad too,
45:35 Brad because I think that like I haven't played around with this yet myself,
45:40 Brad but I feel like.
45:44 Brad 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 Brad you know.
46:03 Brad But I think more and more, if we think about this from a, so again,
46:08 Brad I just feel like there's this whole like confluence of events of like,
46:12 Brad what does it mean to build software well?
46:16 Brad And now we have this notion of we have all of these, you know.
46:21 Brad 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 Brad right?
46:31 Brad Like I'm more convinced than ever that the notion of what are the building blocks necessary to build software well,
46:39 Brad right? Whether that be high quality.
46:44 Brad 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 Brad 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 Scott circle,
47:39 Scott and gherkin.
47:41 Scott Let me come back to all those.
47:42 Brad Okay.
47:43 Scott My colleague,
47:44 Scott Johan Heller, gave a great presentation once to some product managers about the importance of requirements.
47:51 Scott And he said,
47:51 Scott look,
47:52 Scott if you give me a requirement that says you want a square,
47:56 Scott what do you want exactly?
47:58 Scott And he put up on he had one slide and it was a.
48:01 Scott 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 Scott I, well,
48:30 Scott 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 Scott Circles, you just mentioned the word pipeline, and we sort of talk about this in very waterfall-y way,
48:45 Scott but each of these steps actually is a bunch of kind of loops that go around and round,
48:51 Scott and people...
48:54 Scott 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 Scott Each stage is a loop,
49:22 Scott and sometimes it's actually a loop.
49:24 Scott back to the previous stage.
49:25 Scott 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 Scott oh no,
49:32 Scott no,
49:32 Scott that's not what I really wanted.
49:33 Scott And we're going to go back to the beginning.
49:34 Scott 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 Scott what do you call the, the not bullet points when you have the letters and numbers,
49:47 Scott what's that called? An outline.
49:48 Scott I don't know.
49:50 Scott You have an outline.
49:52 Scott It's very hard for us to capture that in writing.
49:56 Brad Yeah.
49:56 Scott Right.
49:57 Scott But it's really the key to the successful thing.
49:59 Scott And the last thing I said was Gherkin.
50:01 Scott I'm not super familiar with this. I've never actually personally used it. But there's this framework.
50:06 Scott I think it's called the Gherkin framework for writing requirements.
50:10 Scott And I once worked at a company where we had this contractor who wrote this thing.
50:16 Scott 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 Scott And I was like,
50:27 Scott whoa,
50:27 Scott well, that's cool,
50:29 Scott but we're not there yet.
50:31 Scott Right.
50:31 Brad Right.
50:31 Scott But now with with AI and vibe coding,
50:37 Scott 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 Brad Okay,
50:49 Brad 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 Brad You know, systems for improving software productivity or development.
51:10 Brad I always like to ask the question,
51:12 Brad well, what are the unintended consequences? What are the what are the potentially toxic side effects that can come from this?
51:18 Brad And I.
51:21 Brad I believe I have seen in practice,
51:24 Brad 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 Brad 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 Scott look, we write code and code has to be precise,
52:07 Scott right? It has to do exactly what it has to.
52:13 Scott There's not ambiguity when the code's written. It does a thing, one thing or the other.
52:17 Scott And sometimes software engineers want their SDLC to like be equally as precise and there's going to be gray areas.
52:25 Scott I see this also just tangentially related to like career leveling guides,
52:30 Scott right?
52:30 Scott 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 Scott And it's like, well, look, we can't write every single thing down.
52:40 Scott with how we make software.
52:42 Scott There is, if you follow these steps from software,
52:45 Scott it's not going to come out right.
52:46 Scott 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 Scott 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 Scott if so-and-so does this and then...
53:05 Scott 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 Brad that's like the conversation around like we can't take everything literally,
53:32 Brad right?
53:32 Scott Yeah.
53:33 Scott And I see engineers getting wound up. They want, it's just their nature,
53:37 Scott 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 Brad I think that's that seems certainly true. And I think that the
53:51 Brad One of the things I've noticed in some organizations where they maybe it's because they get big,
53:58 Brad 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 Brad matrices,
54:15 Brad right? Like,
54:16 Brad well.
54:18 Brad 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 Brad 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 Scott 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 Scott It comes back to the same thing at a certain point, you have to be a team,
55:47 Scott right?
55:47 Scott Yes, you have to be
55:48 Brad Yeah.
55:48 Scott a living,
55:49 Scott breathing,
55:50 Scott collaborating.
55:52 Scott We're in this together to make software. I've said this probably on this podcast,
55:57 Scott software is a team sport,
55:58 Scott right? It takes a village and there's a certain quality,
56:04 Scott qualitative aspect of community and teams that you can't codify.
56:09 Brad Yeah.
56:10 Brad Yeah.
56:11 Brad 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 Scott Maybe.
56:21 Brad Totally.
56:22 Scott I mean, getting to see it work is fun too.
56:26 Brad Yeah,
56:26 Brad I mean, I'll, yeah,
56:27 Brad I think so. I mean, I know that in my career, the thing that gives me the most joy is.
56:36 Brad 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 Scott ladies and gentlemen out there in CTO land,
57:04 Scott remember to tell all your friends to smash that subscribe button to rate and review.
57:09 Scott And we'll see you here next week. Is that right,
57:12 Scott Brad?
57:12 Brad Yeah,
57:12 Brad 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 Brad Our theme song was AI generated by Brad.
57:23 Brad 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