Navigating BADD vs. FaDD: Strategic Refactoring in Software Development

0:00 Scott: A risk of bad is the four most expensive words in the human language,

0:05 while you're at it.

0:24 Hey, Brad,

0:25 how are you doing?

0:26 Brad: I'm doing great. How are you doing, Scott?

0:28 Scott: Good.

0:29 Do you want to record a podcast?

0:30 Brad: Yeah,

0:31 let's do it.

0:32 Scott: What should we call it?

0:33 Brad: How many CTOs does it take?

0:35 Scott: That's right. This is the How Many CTOs Does It Take podcast.

0:38 My name is Scott Porad,

0:39 and this is my trusty co-host.

0:41 Brad: Brad Hefta-Gaub.

0:43 Scott: Brad,

0:44 I've got a question for you today that

0:45 Brad: Yes, tell me.

0:46 Scott: has nothing to do with AI.

0:48 Brad: Okay,

0:49 good.

0:50 Scott: It might have something to do with AI possibly, but I don't think it does.

0:54 Brad: All right,

0:54 Scott: I'm

0:54 Brad: I'm listening.

0:55 Scott: sure AI will come up.

0:57 I want to know what you think of the bad strategy versus the fad strategy.

1:02 Brad: I'm going to have to learn more about the both of those strategies before I can answer.

1:08 Scott: That's right.

1:09 Let me tell you.

1:10 Okay,

1:10 so there is...

1:14 A part of the system at the company I work at, the company wants to refactor. Well,

1:19 it doesn't want to refactor at all. It wants some new functionality in that system.

1:24 And in order to get it there,

1:27 really the code needs to be refactored.

1:30 Okay.

1:31 It's a tangled mess as it is now because it's been hacked on for a lot of years and they want to add a lot of complexity basically to keep it really simple.

1:39 Well,

1:39 imagine if it's a one-to-one relationship now and they want it to be a many-to-many.

1:44 It's just, it's all tangled and they're just going to make it more tangled.

1:47 And so they're on board with, you know, they want to do this and they want us to invest the time to refactor it. We've been able to make that case,

1:54 no problem.

1:55 And a lot of this is actually we don't use the language refactor, we use the language modernize. So that's our issue.

2:03 But let's set that aside.

2:05 Okay.

2:05 So of course there's, you can't go down this pathway without starting the conversation,

2:11 should we start it over from scratch?

2:13 Brad: That good system?

2:15 Scott: And of course we entertain that idea for a week or so,

2:18 and then we're like, this is nuts.

2:20 We're not going to write it over from scratch. We need to refactor it. Okay.

2:22 Brad: Right.

2:22 Scott: So now there's two possible ways you can,

2:26 well, there may be many possible ways you can refactor this, but there are two that I am currently debating.

2:30 Brad: Sure.

2:31 Scott: Let me tell you about the bad strategy and the fad strategy.

2:34 Brad: Okay.

2:35 Scott: They're acronyms.

2:36 Brad: Okay.

2:36 Scott: Bad is B-A-D-D,

2:39 and it stands for Better Architecture Driven Development.

2:44 Brad: Okay.

2:46 Scott: And fad is also an acronym,

2:48 but it's not a very good acronym because it doesn't have all the right letters, but for having a pithy choice,

2:54 it fit.

2:55 And fad is feature-driven development.

3:00 There's no A in it.

3:02 Brad: Now it's FDD fad.

3:04 Scott: It is FDD,

3:05 but I threw that.

3:07 It's really,

3:07 okay, well, let's talk about these things.

3:11 The fad is,

3:12 I think, what we commonly do,

3:14 which is we say,

3:16 okay,

3:16 we want this system to work in this new way,

3:19 so we're going to refactor it.

3:22 As we add these capabilities to the system,

3:25 we are going to refactor along the way so that we deliver the thing that we want to deliver.

3:32 The bad strategy says, no,

3:34 no, no.

3:35 Refactor that thing and just make it work good the way it is,

3:39 and then after it's been refactored, add your new capabilities on top of it.

3:45 Brad: Okay.

3:46 Scott: Now, I want to know what you think. Are you a bad guy or a fad guy?

3:51 And I know your answer,

3:53 which is it depends.

3:54 So upon what does it depend?

3:57 Brad: I Or don't know.

3:58 Scott: should we just explore the pros and cons Let's of bad and explore fat?

4:01 Brad: the pros and cons because I'm not sure.

4:03 Scott: Let me give one more piece of context.

4:04 Brad: Yeah, sure.

4:06 Scott: I have always been a fad guy.

4:08 Brad: I've never felt like I've been asked this question before,

4:10 so

4:11 Scott: Yeah.

4:11 Brad: I was taking a moment to check in with myself to sort of like,

4:16 wait,

4:17 what do I think about?

4:18 Like, I definitely couldn't just like shoot from the hip on this one.

4:25 I

4:25 Scott: Okay,

4:25 Brad: had to check in.

4:26 Scott: let me give you some more context.

4:28 So I've always been a fad guy.

4:29 If you're going to refactor, you refactor in a direction and the direction is toward the capabilities that you want.

4:37 But I was challenged on that in the last couple of weeks by the funniest of people,

4:42 by the CEO and the chief product officer

4:45 Brad: Interesting.

4:45 Scott: of the company I

4:46 Brad: Yeah,

4:46 Scott: work

4:46 Brad: yeah, yeah,

4:47 Scott: at.

4:47 Brad: right.

4:47 Right.

4:47 Scott: I wasn't quite challenged. They didn't intentionally challenge me.

4:51 They just said, well, why are you doing it that way? Why aren't you going to modernize it first and then build it?

4:57 the new stuff on top second that seems like it would be easier and i did all i explained all the reasons why you don't do that right because this gives us actually need to take a step further back i've been pounding the table like hey if you want us to refactor this thing we need some product requirements we need to know

5:16 And not just like product requirements for this little tweak you want us to make, but like long term, where do you want to go with this new

5:21 Brad: Right

5:22 Scott: set of capabilities you want us to have here so we can start building in that direction. They've been saying, why do you want to know that? Aren't you just going to you're just modernizing it. Right. Then after you're done modernizing it, then we'll add the new capabilities on.

5:33 And then I explain,

5:34 well,

5:34 no,

5:34 no,

5:34 we need to do this in a direction. If I give the engineers a blank check,

5:38 they're just going to fix a bunch of stuff and we're not going to get anywhere.

5:41 And, you know, I

5:42 Brad: Well,

5:42 Scott: mean, like the

5:43 Brad: like yeah,

5:43 Scott: engineers would love to do it that way, but that's not the best way for the business.

5:47 But then I thought to myself,

5:48 I mean, these two individuals are not dumb.

5:52 They're executives at a pretty big company.

5:55 Brad: I totally yeah

5:55 Scott: should reflect upon that for a second. Is there something I am missing?

5:59 Why am I a fad guy and not a bad guy?

6:02 And so I've got some further thoughts on that. I can tell you, I can lay more out, but it seems like you got some thoughts.

6:09 Brad: yeah so I've had time to check in with myself um

6:12 Scott: Great. Let's hear it.

6:15 Brad: I feel like the very first reaction that I had well actually when you said I've always been a fad guy that like a little thing went off in my brain going yeah I think I've always been a fad guy too so then I was like okay what why why is that

6:35 i mean bad the the bad better architecture driven development like that feels like second system that's like screaming second system to me and it's funny i actually have this memory oh my god this is so long ago this is 20 years ago at real networks more than 20 years ago because i've been gone for more than 20 years but i remember

6:59 There was a point where essentially one of the dev teams kind of was like, we're going to rewrite everything.

7:07 And they were kind of like this little,

7:09 you know, kind of pirate group,

7:12 you know, they were kind of like they had their their their their leader, their VP level leader was like, screw everybody else, we can do it our own way.

7:22 And.

7:23 They basically effectively made a better architecture argument.

7:31 Like stuff has changed since this code was written.

7:35 There's better ways to do this. It's become this big monolith.

7:38 Why don't we start over and build the small thing?

7:42 And they got a demo working of the top veneer of the features that mattered.

7:51 enough just enough to kind of like keep the momentum going and then they just they got stuck in the churn of trying to build all the new features so it was like classic second system effect well

8:04 Scott: Yeah, that's second system. I don't think that's what bad is. Bad is not second system.

8:09 But here's

8:09 Brad: okay

8:10 Scott: what I envision bad being.

8:11 Brad: tell me

8:13 Scott: Okay,

8:13 you've got a monolith.

8:15 you're going to decompose this into well let's say let's not even decompose it you've got a monolith with a bunch of spaghetti code we're just going to go in there and like we got these methods that are 2,000 lines long and that are recursive and that are all messy and we're just going to refactor this code it's we don't want it to do anything differently than it does today we just want it to be easier to work with

8:37 We've got a monolith, a bunch of code and a giant repo with millions of lines of code. We're going to decompose this into, let's just say, half a dozen different macro services and they're going to talk to each other through some communication mechanism.

8:50 And so I will have a smaller footprint to finish with.

8:53 So we'll just have a better architecture.

8:55 We're going to document our APIs and

8:57 Brad: yeah

8:57 Scott: we're going to have right APIs.

8:58 Brad: but this but this is the but this is yeah but hold on a second so like

9:02 When I hear someone say,

9:04 let's do a better architecture,

9:06 I hear that. And even when I hear you like it'd be one thing if it's like.

9:11 like i mean i i'm i'm dealing with this with one of the one of the teams that i'm working with where we've got just a file that's like 3 000 lines long and it's like oh my god like who let this file get so big well let's start peeling pieces out of it and you end up changing like of course you're not trying to change the behavior but but when you like are like hey this file has become monolithic

9:37 itself is too big let's make let's pull out the helper classes let's pull out you know a bunch of these functions and make them tiny little helper classes instead right like maybe i i guess are you saying that's that's not second system but that's but that's better architecture is

9:54 Scott: That'd

9:54 Brad: that i

9:55 Scott: be an example of refactoring in order to make the code better.

9:58 Don't get too hung up on the word architecture.

10:00 I mean, I was just, you know, I had to come up with some pithy names for these things,

10:03 Brad: see

10:03 Scott: right?

10:03 Right.

10:03 But,

10:04 you know,

10:05 like you're basically saying to the team, look,

10:07 we want to make this code right now. You're saying it takes a long time to build things because the code is a ball of mud.

10:13 Right.

10:13 Brad: Yeah,

10:13 Scott: It's

10:13 Brad: right.

10:13 Scott: your spaghetti code.

10:14 Fine.

10:15 Brad: You just go in

10:15 Scott: We're

10:15 Brad: and unmod

10:15 Scott: going to spend a bunch of time and making it.

10:17 What's that?

10:18 Brad: unmod it

10:19 Scott: Yeah,

10:20 we're going to unmud it.

10:21 That's what we're going to do.

10:22 We're going to make the messy things unmessy. We're going to make the spaghetti untangled and we're going to make it a lot easier.

10:27 And then after we've done that for a while,

10:30 we'll define what maybe what good looks like there.

10:32 But after we've done that,

10:35 then we'll go.

10:36 Now it should be easier to work with, right? Then we'll go add in the stuff that the business wants.

10:40 Brad: Yeah.

10:41 Man,

10:42 I don't know. I'm feeling.

10:46 I'm feeling uneasy about this.

10:48 You sort of said something a few minutes ago that I think is maybe the articulation of what I'm feeling uneasy about.

10:53 You said something like, if I don't give the developers a direction,

10:57 they're just going to go do stuff that

10:59 Scott: Yeah.

10:59 Brad: is not necessarily,

11:01 it just maybe makes them feel better.

11:04 Scott: Yeah.

11:05 Like, well, let's go back to what are we trying to accomplish?

11:08 Brad: Yeah.

11:09 I mean, you said something earlier about what the business goal was.

11:14 It's like essentially pivoting from like a one-to-one relationship to a many-to-many relationship.

11:20 Scott: That's not really what it is. That's just an illustration of like, imagine you had some complex thing and then that's what they wanted to do, right?

11:28 You'd be like, oh my God, we're going to just make this a really tangled ball of mud.

11:31 No,

11:32 it's what's practically happening is the business is saying we want this capability.

11:37 engineering is saying okay it's going to take you this long to get that business is saying that's going to take us too long how could you get it faster the engineers are saying well if this system wasn't so crappy we could get we could build it for you faster like if we weren't having to deal with this ball of mud

11:51 Brad: Yeah.

11:51 Scott: and and the and the business is saying cool fix the ball fix him up great

11:55 Brad: development.

11:56 Scott: yep

11:56 Brad: Yeah.

11:57 Scott: they're saying great fix them we're happy to we're happy to have you fix the ball of mud because you're going to have if it isn't now it's going to be the next thing we want you're going to have to fix it so great fix the ball of mud and then we've arrived at this question of like well how do we fix the ball of mud and the first question you ask is well should we start from scratch and you entertain that for a little bit until you realize that's a fool's errand and then you get to the next thing

12:17 thing which i've always taken the fad approach which is like okay we're going to define what we want the product to be like the software to be like and then as we build towards that we'll refactor along the way to make it less money and i was i used the word challenged i mean i'm the one who took the challenge i don't think they meant to challenge me they were just asking like

12:37 Brad: So why

12:38 Scott: we

12:38 Brad: are you doing

12:39 Scott: thought

12:39 Brad: it that way?

12:41 Scott: Well, they didn't even say why they were just like I assumed you were going to do it this way Why are you doing it? Yeah, I assumed you were going to do it this other way like

12:47 Brad: modernize

12:47 Scott: just to come it in

12:47 Brad: then add features well

12:49 Scott: right

12:49 Brad: i want to try to like i i think this is a super interesting question and i feel like

12:54 I feel like it's worth me challenging why am I uneasy about this?

12:58 Like, what am I uneasy about?

13:00 And I think maybe,

13:01 like,

13:02 let's go down this better architecture driven design approach for a second. Let's go down that. Let's let's

13:07 Scott: Let's

13:07 Brad: try to explore

13:07 Scott: talk about pros

13:08 Brad: what.

13:08 Scott: and cons.

13:08 Brad: Well,

13:09 no,

13:09 before we talk about the pros and cons,

13:11 let's make sure we're clear on what that would look like.

13:15 I'm feeling I'm kind of feeling a little my kinesthetic learning brain is kicking.

13:21 kicking into full gear here and i'm like what would this look like and feel like what would this mean like how

13:28 Scott: Here's

13:28 Brad: would what would

13:28 Scott: what I think

13:28 Brad: we yeah

13:29 Scott: it would look like.

13:29 Brad: yeah tell me

13:31 Scott: It would, I mean, I don't have the definitive answer,

13:34 but I think these are some things that it would look like.

13:37 It would have,

13:38 at the architecture layer,

13:41 it would take the monolith and break it into,

13:44 let's just say, half a dozen major chunks.

13:47 meaningful domains and those chunks would communicate via messages with each other at the code layer it would look like let's just call it

14:01 fixing a lot of the unbest practices but the worst practices right the get getting rid of the you know taking the 3 000 line files and fixing them those kinds of things that the code you know this is a system that has a lot of it's written in ruby and ruby sort of it uses a ruby on rails and so it has this active record spawns these events you know on save and on update and on these things and people have tapped into those

14:28 into those and it makes navigating the code very complex and so maybe you straighten some of that stuff up so that people who are trying to reason about how the system works it might not be taking advantage of all the ruby and ruby on rails magic but it would be for a large team of developers it would be easier to reason about you would write documentation or have ai write documentation for you so that people understood how the things work you know you do those kinds of things you maybe would refactor

14:53 refactor some of your databases like your database well you certainly as you broke at the architectural level as you broke your system into domains you'd separate out your data but even within a given domain when you're refactoring code you might say look the way these tables are constructed

15:10 isn't is inefficient or it doesn't make sense anymore i think ultimately so what are you trying to do like conceptually what you're trying to do is make it faster for engineers to develop

15:22 So strategically, what you're saying is if I can create smaller components and within those components, they can follow more of the best practices,

15:29 you know, all the things from test automation on down,

15:32 then it'll be easier and faster for engineers to get things

15:35 Brad: Right.

15:35 Scott: done.

15:35 That's

15:35 Brad: Okay.

15:35 Scott: the idea.

15:36 Brad: Okay,

15:36 cool.

15:37 So I,

15:38 that's, I'm, that sounds like a really good answer.

15:42 What pops into my mind is, for example, I was working with this, you know.

15:48 my the team i spend almost all my time with is a team that we recently were like god we've got these 3 000 line files we should figure this out we should basically like modularize this stuff and so as a team we wrote up like a working agreement to use your language about code modularization and we're like guiding principles you know single responsibility principle low coupling high cohesion maintainability test right so we like wrote up

16:13 wrote up a working agreement there and i could totally imagine a world where maybe you already have those like coding standards or guide you know kind of architecture like like because to me right like this this is like this is like totally you know giving uh the the conversation that we had with ted neward about like um look there are no such things as best practices there's just practices that as a team you've agreed to you

16:37 Right.

16:37 Scott: Sure.

16:38 Brad: And so the first step is like, OK,

16:40 do we have working agreements on all of our what this code, what what good architecture looks like, but what better architecture looks like?

16:48 And then I guess I could totally imagine a world where like you basically get a whole bunch of like we're all aligned on these.

16:54 what better architecture looks like and then we essentially go on a module by module basis component by component basis file by file basis and we you know we somehow like score it and say yep this one is not meeting our definition of better architecture ted you get to go re-implement this file to have single responsibility principle

17:22 And

17:22 Scott: Sure.

17:23 Brad: Ted gets to own, you know, whatever, whatever scale task that is for that file or,

17:28 Scott: Yeah,

17:28 Brad: or, or, you know, work through it.

17:31 Is that kind of what, what

17:33 Scott: it could be

17:34 Brad: looked just like like.

17:34 Scott: that.

17:35 Or you could take it from the perspective of pain points, you could ask your team, well, what makes it hard?

17:39 And they might say,

17:40 well, the fact that we have files that have 10 different concepts in them makes it really confusing to figure out how stuff works.

17:47 So maybe

17:49 So you can take it from that perspective,

17:50 like there's a lot of ways you could get in like Ted said you just agree on what you want to agree on whatever the best practice is that we're going to single responsibility or no files bigger than a thousand lines or whatever it is right.

18:03 Brad: Right.

18:04 Scott: Tabs, not spaces,

18:05 you know, spaces,

18:06 Brad: Yeah,

18:06 totally.

18:07 Well,

18:07 Scott: not tabs.

18:08 Brad: I'm also a big believer that anything that can be enforced with lint and prettier.

18:15 We should just enforce

18:16 Scott: Sure.

18:17 Brad: with lint and prettier.

18:18 Scott: Well,

18:18 I was just joking about the tabs and spaces thing. But yeah, I think that's exactly the approach you would take.

18:25 And it seems like, you know,

18:27 what are the pros?

18:28 It's really like you can determine if it was done correctly,

18:32 meaning does the system work the same way it worked before?

18:36 You're not.

18:37 you're not trying to do two things at once you're just trying to you know there's some of the interesting things about software or some of our principles of software engineering like you know only try to do one thing at a time don't make a commit that does two things make commit that does one thing so it's easy well fundamentally with fad we're trying to do two things at a time with

18:57 Brad: Yeah,

18:57 Scott: bad we're trying to do one thing at a time right that's those are pros

19:01 Brad: I would argue that.

19:03 That there's a step that both these approaches require,

19:07 which is your first step,

19:08 which is alignment on what the better architecture is.

19:11 So maybe,

19:12 Scott: Yes.

19:12 Brad: you know what I mean, like if you really are going to do fad correctly,

19:16 then you do have to agree on the better architecture before you even start building new features.

19:22 Because you

19:22 Scott: Absolutely.

19:22 Brad: said you were going to build the new features with the better architecture.

19:26 So that's

19:26 Scott: Well, so you have to agree on the architecture on both sides.

19:29 But on one side, you don't have to agree on the product requirements.

19:34 Brad: fair.

19:34 Scott: You just need to make sure you don't break it.

19:37 Brad: and and and were you partly inspired by this because I think this way you told the story was you're like yeah okay let's go down this road by the way we need to know what the what your vision and product requirements are and

19:47 Scott: Yeah, I've been

19:48 Brad: they were

19:48 Scott: pushing

19:48 Brad: like

19:48 Scott: on

19:48 Brad: well

19:48 Scott: the product requirements.

19:49 Brad: wait why do you need that why do you need that don't you want to like modernize it

19:53 Scott: Yeah,

19:54 that's exactly right.

19:54 I've been saying we can't get started until we write the requirements.

19:57 And they've been like, well, why?

19:59 organizing it first i was like well yeah we are modernizing but we need to know like what we're working toward and they're like well don't you modernize first and then we add on the stuff we want and i explained oh no that's not why you do it because you know if we do it this other way we get the business value faster because maybe you get some incremental gains along the way and we get the scope right so that we're not building stuff that doesn't matter and um

20:22 Brad: But

20:23 Scott: you

20:23 Brad: then there are, yeah,

20:23 Scott: know

20:24 Brad: so I agree.

20:24 I obviously agree with all that stuff, and that's why knowing

20:26 Scott: Yeah

20:27 Brad: the direction you're going.

20:29 You know, because there's like there's always six ways to do something,

20:32 all of which are not wrong, but

20:34 Scott: Right.

20:35 Brad: one of them is going to, you know, some of those will improve your chances of doing the future thing and others will make it harder to do the future thing.

20:43 Scott: Yeah.

20:43 And I made the argument like, you know, hey, it's like you're asking me to, hey, you want to add two bedroom, you got this old rundown house and I want to update the whole house and add on two bedrooms and you're asking me to update the whole house.

20:55 And then once that's all done, have

20:57 Brad: But

20:57 Scott: the construction

20:57 Brad: add

20:58 Scott: crew

20:58 Brad: the

20:58 Scott: come back and add the two bedrooms and nobody would do that,

21:01 right?

21:03 So here's a few of the thoughts.

21:05 Brad: But they also but, you know, I guess if we're using our house renovation analogy,

21:10 it wouldn't be wrong to say, but wait, you just told me there was knob and tube wiring all over the existing infrastructure and.

21:18 You know, you're like, that's not modern. Let's put true new modern electrical in.

21:24 You could certainly do that to the part that's standing,

21:27 even though we haven't done the design on the new addition.

21:34 Scott: Yeah, you could.

21:37 unless you thought well i used a let's actually not use an addition because that's not what we're talking about here by the way as an addition we're talking about remodeling the layout of the house we're

21:46 Brad: Yeah, we're going from

21:46 Scott: remodeling

21:47 Brad: we're

21:47 Scott: the kitchen going this

21:47 Brad: from to

21:48 Scott: is actually open we

21:48 Brad: open floor plan

21:49 Scott: work well actually let's do this way we want to totally update this kitchen make it modern new appliances you know the best in the best in refrigeration that you can possibly have and then after it's done we're going to get rid of all that

22:02 that and we're going to come in and put in a new kitchen with like an island and a better cutting board and all sorts of stuff right that's kind of what it is okay

22:08 Brad: Yeah, that would be nice.

22:08 Scott: so here there's just two other thoughts that come across my head a risk of bad is the four most expensive words in the human language while you're at it yep

22:25 And so one risk of fad is that your business

22:27 Brad: Or

22:28 Scott: doesn't

22:28 Brad: what, is it,

22:28 Scott: have the discipline,

22:28 Brad: it's, wait,

22:29 Scott: I'm sorry, bad,

22:29 Brad: wait, wait.

22:30 Scott: a

22:30 Brad: Yeah, okay.

22:31 Scott: risk of bad is that your company doesn't have the discipline to actually do it, right?

22:36 Brad: Yeah, so you end up fatting.

22:38 Scott: You end up fatting, but you end up fatting without good requirements because your engineers have got the patient open and they're like, oh, and now you want me to stick in the new refrigerator?

22:47 Okay,

22:48 well,

22:48 I guess I'll just hack this in here.

22:51 That's one risk.

22:52 Another risk is, so you do it. You're at the end of the modernization.

22:57 The house,

22:58 the kitchen,

22:58 it's all sweet.

22:59 And the business is like,

23:01 what did I get for that?

23:04 Well, now we can build stuff faster.

23:06 Okay,

23:06 cool.

23:07 Now I want you to build this new thing.

23:08 Okay, well, that's going to take eight months.

23:10 Well,

23:11 I thought it was going to be a lot faster than that.

23:13 Well, before it was going to be.

23:15 18 months now it's 28 months they're like yeah but I wanted it like in two or three months right

23:19 Brad: Yeah, yeah, totally.

23:20 Scott: so there's there's

23:20 Brad: I think

23:21 Scott: a risk

23:21 Brad: that's I think that's your biggest risk.

23:23 Like you might have oversold how much easier this is.

23:26 Some stuff

23:26 Scott: I

23:26 Brad: is

23:26 Scott: haven't

23:26 Brad: hard to

23:27 Scott: sold

23:27 Brad: do.

23:27 Scott: it at all I don't I don't know I literally couldn't tell you how much faster it's going to go because

23:30 Brad: No, no, no, I just mean,

23:31 Scott: don't know what you want me to build

23:38 Brad: yeah,

23:39 that's yes,

23:39 yes,

23:40 yes, yes.

23:41 I think that like.

23:43 Yeah, man.

23:44 I

23:45 Scott: Okay,

23:45 Brad: mean,

23:45 Scott: wait, here's another wrinkle.

23:46 Brad: okay, tell me.

23:48 Scott: Is it possible that we,

23:50 and I said like almost every person I've talked to about this has said fad. Every engineering leader has said fad.

23:59 Is

23:59 Brad: That's

23:59 Scott: it possible?

23:59 Brad: where I felt the pull to.

24:03 Scott: It's totally, it's totally where I go to totally was okay.

24:07 But is it because of this? I have never been able to successfully sell.

24:13 bad to the business stakeholders and

24:15 Brad: Yeah, you're

24:16 Scott: then the occasions that i have like it's been a little disappointing but i've never they never buy into that because they're like well what am i going to get for my money and you're like you're going to get faster stuff how much faster i don't really know they're like no i'm not going to do that so in order to actually do modernizations in my career i've had to learn the technique of bad which is okay you want this thing we're going to add a tax to this thing which is doing the modernization work and you can't

24:40 You can't remodel the kitchen without doing the knob and tube wiring.

24:45 So we've got a tech.

24:46 And so we've learned how to do fad because it was actually the only way that we could do the modernization because

24:53 Brad: Modernization.

24:54 Scott: we couldn't ever quantify or express the value of the modernization.

24:58 And I now find myself in a unique situation.

25:01 Brad: Your bluff has been called.

25:03 Scott: It's not even a bluff.

25:04 It's just like I'm not having to sell it. They're actually saying,

25:06 why aren't you taking it?

25:08 And I was so thrown for a loop. I was like, wait a second, why aren't I taking it?

25:13 Brad: Right.

25:14 Why aren't

25:15 Scott: So

25:15 Brad: you taking

25:15 Scott: I wonder

25:15 Brad: it?

25:15 Scott: if it's just like I'm scarred. I got like, you know, wounded puppy or abused puppy syndrome.

25:20 Brad: Right.

25:21 Right.

25:22 Right.

25:24 We're just trying to give you some wet food.

25:26 I don't know what you're so skittish about.

25:30 Scott: And so here's another puzzle piece.

25:32 as i said every engineering leader i've talked to including ones inside my own company they instantly go to fad they were like well that's crazy because they've all had the same experience that i've had in their careers which

25:44 Brad: Right.

25:44 Scott: is like oh bad is terrible every time we've ever tried to do bad every time we propose bad they shut us down and even we do it

25:52 They get impatient and cut it off partway through,

25:54 so we actually never get the value from it.

25:57 So

25:57 Brad: that

25:57 Scott: that we've

25:57 Brad: that's

25:57 Scott: missed learning

25:58 Brad: like that

25:58 Scott: to do fast.

25:58 Brad: right there is a real that's a real concern that right

26:02 Scott: Yeah,

26:02 Brad: there is

26:02 Scott: it is real concern.

26:02 Brad: because you get halfway halfway done with the bad and you've got nothing and then they get then they get skittish and and stop it like that's that's like i think that's a real legit concern

26:12 Scott: As a matter of fact, I have that in two places in our system right now.

26:19 before I started at this company they went about upgrading from some front-end framework to another front-end framework of course only finished two-thirds of it and so now the front-end developers are frustrated they got to deal with both not only do they have to deal with the bad one they deal with the bad one and the new one right that's the worst of both worlds and

26:39 Brad: Right.

26:40 Scott: then we have a project where we were

26:43 rebuilding refactoring a key part of the system and wanting to extract it out of the monolith and their idea was we'll build it inside the monolith first and then extract it out well they finished about 80 of it inside the monolith and then stopped so they got now they have this particular subsystem there's two of them running both inside the monolith side by side and so they first they got to finish it and then they got extra and so

27:08 every you know on the first case which was purely bad um they just didn't get finished the second case was actually fad and it didn't get finished and in this case you got business stakeholders saying like what those guys worked on that for like three years you're telling me it's not done hundreds

27:24 Brad: Yeah, 100% agree with everything you just said. I've seen that happen hundreds of times. It's like, of course gonna happen.

27:29 Scott: of

27:29 Brad: It's of course gonna happen.

27:30 Scott: course

27:31 Brad: So the question then is,

27:35 So as we were talking about this earlier,

27:37 I was imagining,

27:38 well,

27:39 maybe what you do is you.

27:42 You do these working,

27:43 you agree,

27:44 you come to agreement within the team about what good architecture is, what better architecture is.

27:49 You stack rank the, and I love your point,

27:52 like ask them what's taking them, you know, ask them what's hard,

27:54 ask them what makes it hard.

27:55 You stack rank the stuff that's going to make the biggest difference to the developers'

27:59 productivity and velocity,

28:01 right?

28:01 Like that's what this is all about.

28:02 This is all about can we make it more high velocity developers,

28:05 right? Because you're not, because I'm assuming that you're not dealing with the...

28:09 the rickety system that has these you know hard to you know constantly falling over bugs right but but but even if you had that it wouldn't matter you still do an analysis where you're like what's the thing that as a team we genuinely believe that if we make progress against these goals we will have higher velocity

28:30 Scott: Yeah, one

28:30 Brad: And then you rank those things like which ones do we to the best of our professional ability believe are going to make the biggest difference in velocity.

28:39 And then.

28:41 You you bite size those and you you know, what's the saying?

28:46 How do you eat an elephant?

28:48 One bite at a time.

28:49 Scott: bite at the time. Yeah.

28:50 Brad: And so you you've set a set of you've you've created a punch list.

28:57 or like a meta punch list that

28:59 Scott: Hmm.

28:59 Brad: is that is to the best of your professional opinion the thing that's going to increase velocity the fastest and you start working through that punch list and each point along the way you make sure you've you've you've hit a checkpoint that you've made a difference and then before you move to the next bite right and then at any point along the way

29:24 You're able to stop.

29:25 You're able to stop working on it and move on to back to features.

29:31 Scott: Yeah,

29:31 I think what you're saying is if you go down a bad route,

29:34 you really need to be incremental so that you can stop.

29:38 You need to swarm around things and get them finished, not have many things in flight that are partially finished.

29:45 Brad: And then.

29:49 as you're doing that features can also slot in so long

29:53 Scott: Mm hmm.

29:54 Brad: as the features are done following the better architecture agreements and

30:00 Scott: Yes.

30:01 Don't

30:01 Brad: so

30:01 Scott: make it worse.

30:02 Stop digging the hole deeper.

30:03 Brad: yeah and so i sort of was like that's how i would that's how i think i would approach it and i was like maybe that's something like

30:13 Bad wafad.

30:15 It's like, it's

30:16 Scott: It's a version

30:18 Brad: bad with fad.

30:18 Scott: of hybrid.

30:19 It's

30:20 Brad: It's

30:20 Scott: a version of hybrid.

30:21 Brad: It's bad, not fad, not

30:25 Scott: The

30:25 Brad: bad.

30:25 Scott: hybrid I've had in my mind is slightly different,

30:28 which is there are parts of the system where you might want to do bad. So like that front end framework.

30:38 thing i was just talking about that was just bad right that was just like we used i don't even know what the frameworks really we used angular and now we want to use react like that's just i mean i don't know if that's a trade-up or not but like the it might just be a lateral move so yeah

30:52 Brad: don't get the listeners fighting with each other it's

30:54 Scott: i don't want to obviously not not

30:56 Brad: answers

30:56 Scott: trying to start

30:56 Brad: obvious no it's spelt is obviously the right answer i mean come on

31:00 Scott: right so exactly of course so i'm not trying to get in a fight here i'm just trying to say like

31:05 That's just bad, right?

31:06 Brad: Better

31:07 Scott: We just architecture. want to better architecture.

31:09 Hey,

31:10 we've got two mobile apps.

31:11 One of those mobile apps talks to our backend via GraphQL and the other talks to the backend via REST.

31:18 You know what? We're going to make them just both talk the same way.

31:21 I don't care which one, but why do we maintain two interfaces for this is silly.

31:25 Brad: Yep.

31:25 Scott: Setting aside that you might want a BFF for each app separately,

31:30 the point is.

31:31 it just adds complexity to the whole thing i now have to know two things and think about it differently etc um taking that piece of that component that i just mentioned a few minutes ago that's 80 done just finish it and extract it any extractions are just bad certain extractions are just bad just like just take this chunk extract it take this there's no there's no but there's some pieces like when we were talking about the one-to-one versus the one-to-many piece earlier

31:58 That might be a fad where we say this piece,

32:03 actually, we do want new functionality here.

32:06 And so we're going to do fad on this one.

32:12 And let's be intentional about that.

32:14 Let's not do fad everywhere.

32:15 Let's do fad where we think it's high leverage or high value.

32:20 Brad: Yeah, and it's so I feel like there's two pieces of this hybrid strategy that we're kind of coalescing on.

32:30 One of them is never just.

32:34 open up the entire system and put everything on you know just never never take the whole thing apart you're always going to be on the bad you're always being incremental you're thinking about it you're being intentional about always having stop points and break points and then that way if you have to stop your improvement your architecture improvement mid investment you're never left with hanging

32:59 hanging components and

33:01 Scott: Mm-hmm.

33:01 Brad: then part two if you've clearly articulated your better architecture agreements then it's there's nothing wrong with slotting in an intentional feature uh

33:13 Scott: Or

33:13 Brad: that is

33:14 Scott: an intentional fad.

33:16 Brad: all new features definitionally should

33:18 Scott: All

33:18 Brad: be yeah

33:18 Scott: new features should be fad. Yes.

33:22 Brad: You're going to do all new features as compliant with the new agreed upon better architecture.

33:27 Scott: Well,

33:27 that's a very interesting thing. I was talking to one person today,

33:30 a woman on our team who's one of our leaders,

33:32 and we were talking about that piece,

33:36 which is she was we were discussing this topic and she was saying how she felt like this is all great.

33:47 But there's this piece of our culture that needs to change,

33:50 which is, as you summarize it with this, everything is fat.

33:55 She sort of said, look,

33:56 we got to get to a situation where people don't make things worse,

34:00 right? Right now, there's this, in the name of going fast,

34:05 getting stuff done,

34:06 people dig the hole deeper. And if I've said it once, I've said it a thousand times,

34:10 the fastest way to get out of a hole is stop digging.

34:14 But we still dig.

34:15 And so this is what she was saying,

34:17 which was, Scott,

34:19 this sounds fantastic.

34:20 Like, I love that we're going to do this stuff, whether it's fad or bad,

34:24 I don't really care.

34:24 But it doesn't matter if we don't actually get a culture of, to use your language,

34:29 that we're always fad, that everything we touch, we try and make it better,

34:32 a little bit at least.

34:34 Brad: Yeah.

34:35 Well.

34:36 There you go.

34:37 I guess we landed on it. We actually made the case for how to do bad and fad at the same time, so long as you follow these rules.

34:46 Scott: And it's called HAD.

34:48 Brad: It's called HAD.

34:49 We had the discussion and we landed on HAD.

34:52 Scott: I think there's one other thing to take from this, which is, this is a lesson I've learned from it.

34:58 Our non-technical stakeholders can sometimes at least.

35:03 open up our minds to things that maybe we didn't think about or

35:06 Brad: Yeah.

35:06 Scott: at least or cause us to think is a strongly held belief I have why do I have that strongly held belief is it true is it just due to the scars of previous situations and you

35:22 know be open-minded it's been an enjoyable thought process for me

35:27 Brad: Yeah,

35:27 totally.

35:28 That sounds good. It sounds awesome.

35:30 Scott: Now I just got to get, you know, every other technical leader I've talked to on this topic to change their mind.

35:37 Brad: Oh,

35:37 man. Well,

35:38 I am so happy that you brought this topic.

35:40 This is it's got me thinking it's a pretty cool concept.

35:44 Scott: Yeah,

35:45 the last thing I'll say is I, you know, I talked to about, say two weeks ago, I was talking to the head of product about it.

35:52 Maybe earlier this week I was talking to our CEO kind of having the same conversation and I did just stop for a minute and I was like, huh,

35:58 they're smart people and they're asking me something and why,

36:03 what,

36:04 you know, they caused me to be reflective and that was, I'm glad that I caught myself and did that and I hope I continue to do that.

36:10 Brad: Love it, man.

36:12 Scott: All right. Well, is that it for today?

36:14 Brad: That's it for today.

36:15 sounds like we hit some we landed we landed someplace real we should you know what when you land stop

36:21 Scott: Land.

36:21 Brad: moving land

36:22 Scott: Yeah.

36:22 Brad: mad

36:23 Scott: So I've got a new framework.

36:25 It's called Shad.

36:27 It's called smash that subscribe button.

36:32 Rad rate and review and tell all your friends about us.

36:40 All

36:40 Brad: All

36:40 Scott: right.

36:40 Brad: right.

36:40 Scott: Talk to you soon,

36:41 Brad.

36:43 Brad: This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigow.

36:47 Our theme song was AI Generated by Brad.

36:51 Please follow us on all the social media platforms at at HowManyCTOsPod.

36:56 You can find us on YouTube,

36:58 LinkedIn,

36:59 Instagram,

36:59 Facebook,

37:00 Threads, X,

37:01 TikTok,

37:01 and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice.

37:13 Thanks for listening.