Isaac Askew: Welcome to Never Rewrite. I'm Isaac Askew. Jeffrey Sherman: And I'm Jeffrey Sherman. And today we're going to discuss the goal and how it is a newly re-relevant book. So The Goal Isaac Askew: Mm-hmm. Jeffrey Sherman: is a relatively old book. It's like 40 plus years old. It's written by who was it written by? Sorry, I'm gonna look. Anyway, it's written by a guy named Iliahu Goldrat and Jeff Cox. And The idea is it it's one of the it's an early business story books, right? So it's got the it's a guy working at a factory and the factory Isaac Askew: I hate this style. Jeffrey Sherman: the factory is in trouble and he gets a mentor and the mentor guides him through the journey of discovery. Isaac Askew: that's like the other other the Kim story. Not Phoenix Project, but the same author. Jeffrey Sherman: Yes. Isaac Askew: Right, the Phoenix project, what is that? Da da da da da. This is totally totally Jeffrey Sherman: So w Isaac Askew: important. Jeffrey Sherman: Yes. Interrupt the flow. Isaac Askew: Jean Kim, yeah. Jeffrey Sherman: Yeah, Jin Ken. Yes, it's that style of book. And the thing that they are talking about, the thing that that this book concentrates on, is the theory of constraints, which leads you to just in time shipping. And The book is all about physical manufacturing. They're making radios or something. But the the point of the book is if you opt like the the main message is if you optimize anything that isn't your main constraint, you are likely not only making the system more efficient, but you are probably hurting overall efficiency. And this goes to work in progress and it goes to throughput and basically The whole thing is if you're not anything that doesn't get you more throughput Or get it through the system faster is just making things worse. And so in this in the book they've got this warehouse is full of parts and things because every manager is optimizing, you know, buying equipment and optimizing their own little piece of the the assembly line, but it doesn't Isaac Askew: Right. Jeffrey Sherman: make anything faster because if I remember the book right, the thing that really slow is the bottleneck is the heat treatment plant. Isaac Askew: Okay. Jeffrey Sherman: And so it doesn't matter how quickly you cut this stuff because you still need to sit it in the heat treatment for twelve hours or something. And Isaac Askew: Hm. Jeffrey Sherman: I saw someone bring it up because this is it it's a newly relevant thing because in this world of AI development we have, the constraint, your primary constraint has changed. It used to be the primary thing, the the bottleneck was the ability to write code and get create PRs. And with AI and agentic thing, that's not the bottleneck anymore. Isaac Askew: Well, I got a question and from this particular flow. I guess I I in in the in the plant style thing, it kinda makes sense because your main bottleneck, I could see it being like one particular thing. I feel like there's like sometimes multiple bottlenecks when we're working with in software because like if it's like a database problem, that would be the main thing. That would slow everything down. That would maybe be the analog to the heat treatment thing. but if there's like particular like seventeen different features and some of them are different varying levels of slow or not working, then even if you're not working on the main issue at the company, maybe it's not that the database is an issue, you can still work on something else in your own area of the plant and still optimize that and the customer might still feel it. So I'm kinda wondering, does it always have to be this one true bottleneck that slows down everything? 'Cause if you're saying If you're not working on the main constraint, then it's you know, it's just making it worse. Well, depends on if your main constraint is truly something that ties everything down and not just one thing down. Jeffrey Sherman: Well, I think in this analogy the difference would be the assembly line is for making one product. And you're describing something where you're making multiple products. If you consider each pro like feature that Isaac Askew: Mm, yeah. Jeffrey Sherman: is independent. So if you had this factory and it had multiple assembly lines or multiple things that it was building, each one of those things would have its own individual bottleneck. Isaac Askew: okay. Then I'm on the same page. Each of these seventeen features, let's just call them each seventeen different assembly lines. So when we say I'm working on the main one, we're working on the main feature. If you're not working on the main problem of that feature, then you're just making it worse. Okay. Jeffrey Sherman: Right. And in the software analogy, you may not be making it worse, but you're still probably not gonna make it better. Isaac Askew: Mm. Jeffrey Sherman: Like one thing that I did over the years, I was working on a importer. Right, here's a data importer, and people have been making pieces of that importer more efficient. It's like, okay, it's you know it's gonna import contacts and it's gonna import tags and it's gonna import all these other fields, and I'm gonna make the contacts faster. I'm like, okay. But is that the bot like is that the bottleneck? and in this one, it's Isaac Askew: Yeah. Jeffrey Sherman: like, okay, well, you know, it's not making anything worse, but if you You make a feature that or a piece of the line that is two percent of the total time, and you make that fifty percent faster, okay, now it's gonna be one percent of the total time, and you've knocked one Isaac Askew: Mm-hmm. Jeffrey Sherman: percent off, even though you made this this one section fifty percent faster. Like there's no there's not enough juice there to make it worthwhile. And so Isaac Askew: Right. Yep. Jeffrey Sherman: you'd wanna you'd wanna identify before you started working, you'd wanna identify where are the bottlenecks 'cause those are the places where applying leverage actually matters. Where if you don't see but that was in the before time 'cause now I'm having Isaac Askew: Mm-hmm. Jeffrey Sherman: a different problem. Well and I was thinking about this book recently. Where I set Claude, I said, hey Claude, here is my log stream. I want you to go back and find everything that's error, error out in the last 24 hours, and I want you to, you know, aggregate it together and summarize it and give me a list. And it came back. It's like, okay, here's 15 things that I found. And it was like Isaac Askew: Mm-hmm. Jeffrey Sherman: 10 of them were just missed null checks. Where it's like, if you just checked for null and returned invalid data, you would have returned four four, but because we didn't, we it retur it five hundred. It crashed. It's Isaac Askew: Okay. Jeffrey Sherman: like okay, well these are trivial. and the other five were like out of error out of memory errors. It's like, okay, there's some meat there. And I was like, okay, Isaac Askew: Mm-hmm. Jeffrey Sherman: Claude, you know, fan out sub agents, do all the work. And and Claude says, Yes, sir. It doesn't actually say that, it's not. Ugh, why why would Isaac Askew: You can make it do it. Jeffrey Sherman: you want to? But anyway, Isaac Askew: Okay, it says yes sir. Jeffrey Sherman: so it says yes, sir, and it it it goes and so the null checks come back quickly. It's like, yep, here's the null check, and if the the null fails, then I'm gonna return you know invalid data. So it'll return a 404 or a 400 saying you didn't give me what I need instead of lighting that through and then having the database query crash. It's like cool. So now I have ten PRs. And whereas before, but if I was doing these manually, I would find one, fix it, put out a PR, go to the next one, find it, fix it, put out a PR. With with Claude it found the ten, it fixed the ten, and now I've got ten PRs. and so I don't want to jam the other teams with here's five things. Like you know if one team owns five of of these null checks, I don't give them all five at once, or maybe I do, but it's like okay, here you go. Now they've got to now I've got to wait. And now I've Isaac Askew: Okay, yeah. Jeffrey Sherman: got nothing to do. So I've because I've changed how I'm doing things with Claude, it has changed my bottleneck. My bottleneck is no longer writing the code or finding the errors. it is getting the approvals. Isaac Askew: Mm-hmm. Jeffrey Sherman: A and so it has changed. So look now Claude has changed and the bottleneck is different and I need to rethink how I'm going to or we need to reassess how we're doing PRs Isaac Askew: Right. Jeffrey Sherman: because now PRs are the bottleneck. Isaac Askew: Yeah, I've noticed I've ran into a similar flow. where the approvals approvals are slightly easier than the QA. The QA is the slowest part. because I can spin up so many things that sometimes it's it makes more sense to to put them in one package. Like the PR make the Pig R bigger, which is traditionally not a good idea. But for me, like I almost like if if I'm testing one area and one QA person can spend all their time testing Every flow then testing to make sure no regressions happened, which would be redundant if they tested over and over again for each PR, if i if if the PR is in the same area. Then in my head I'm like, okay, well, I'm gonna have these at least be separate commits for the sake of keeping them clean, but I might actually have somebody review all those null checks, for example, in the same PR. That way QA doesn't get bottlenecked. and we don't sp waste time regression testing each one in between. Because that was what I ran into. And I I I kind of got stuck at that part because part of me, you know, w we always are told to keep our at least if you're not if you're not don't have clean commits in between each one, because sometimes people rebase and put everything to one commit. That that doesn't make sense if you end up doing in this flow, because I want them I want the commits to tell Claw what has happened historically, and that's really valuable for Claw for Claw. but having them as separate PRs doesn't make as much sense anymore just because of that bottleneck. So I know if that's something that you can try or if that's it depends on how big the changes are, 'cause then like, you know if it's five null checks, that's seems to be easy to review and put in one to one PR with five different commits. If it's five huge PRs, that's a really difficult to review, right? Jeffrey Sherman: Right. Well and that's why the example that I led with was the I've got ten null checks. So the these are each like two liners. If is null then Isaac Askew: Right. Jeffrey Sherman: you know, return, kick it out. and so you could do that. And that's the kind of stuff that the goal talks about is doing these suboptimal things, because that suboptimal will will work against the bottleneck. And Isaac Askew: Mm-hmm. Jeffrey Sherman: the bot you in software development, the bottleneck is always the human parts. Isaac Askew: Yep, makes sense. Jeffrey Sherman: Right. And you're talking you've got this QA bottleneck and and so the optimization is, hey, you're now you're redoing your code creation flow to optimize for Isaac Askew: Mm-hmm. Jeffrey Sherman: the QA. Whereas before you would never have done you didn't want to do that. You still don't want to do that. It's less efficient from the coding perspective, but the coding is no longer the bottleneck. So then you're rethinking it, you're saying, Hey, I I now need to re op I now need to optimize for the QA bottleneck. Isaac Askew: I can kinda almost see us going towards slower releases, which is kind of a funny 180, right? Where before it's like release every day, because we don't want to do a quarterly release. Some companies will do like release every week or every two weeks. But we're going back to this flow now where like yeah, we're like there is some tricky webhooks code I was fixing, right? Webhooks is very, very important as a server to like to receive webhooks and be live. And to continue working when you have hundreds coming in from all these different services that respond with what has happened on their party, right? So testing it is very thorough and very slow. And so whenever you make a change, everyone's like, well, we should bundle it with some other updates too, because while we're gonna do all this super thorough testing and maybe some security upgrades and this and that and that, may as well go ahead and start packaging in everything with it because QA will take a long time otherwise 'cause we have to keep redoing this whole really meticulous process. So I could kind of see a world in which okay, let's just bundle it and do a webhooks release every two weeks and slow down the release cycle. 'Cause it's g and now we're going back again. Jeffrey Sherman: Yeah. And that's more risky. Isaac Askew: Right, yeah. Jeffrey Sherman: Right it it you hate it, but it is more effective. and I think we should make clear here that the the key piece here is that this this is a manual human step and that if you could automate the testing, the QA, with you know some end to end or playwright test or something. then that would also work against the your current bottleneck. It's like, well, now if QA is the bottleneck, we should put resources into automating QA so it's no longer the bottleneck. Or, you know, in the short term, make your other things less efficient so that you can make your b QA more efficient. Isaac Askew: Yeah, WebBooks is a tricky example because it's it's not front end at all, right? It's all back end, easy. and automatable. So there's a ton of unit tests that, you know, you can make us feel a little bit safe. The only thing usually you're sanity checking is if you have to upgrade a a library to a major version. you have to make sure that sure both keys work in staging and prod and things like that. But QA usually gets bottlenecked more so, and we talked about this before with front end stuff where Claude is still kind of like I work with it and every now and then it generates a weird placement for a button. I'm like, that is not what the Figma looks like. Why did you think it was? You have access Jeffrey Sherman: Ha ha ha Isaac Askew: to the Figma and the what you need to change for the DOM. Like, why are you getting confused here? So it requires kind of a spot check on the flow. And then it can also, even if the the design is right and everyone thought through that, what if as you're stepping through it just feels clunky and you didn't consider, well maybe we should just go ahead and let them go to the next step? Why don't we asynchronously do work instead of waiting because that work takes a long time and we don't need it in the next step. So as long as we have the return values before the end flow before they submit the form, then we can optimize this to make it feel fast. It doesn't get that kind of thing yet. Right. So trying to optimize that's why the QA is still needed Jeffrey Sherman: Yeah. Well that's the kind of thing that you won't see Isaac Askew: in those flows. Yeah. Jeffrey Sherman: R well that's why you want to keep your releases small and tight so that you can see that. Like, well I changed this and now I I see that this there's a second optimization I should do because Isaac Askew: Mm-hmm. Jeffrey Sherman: I've done the first one. But you won't see it until you try to to release it and so the bigger release works against you. Hmm. Isaac Askew: Right. And so that's where the QA gets more bottlenecked. Any kind of front end or or experience feel flow. This feels clunky or something about it just looks unprofessional. Even if the style is perfect, it's so GeoCities. It's so MySpace. We should make this look more modern. You know, that's Jeffrey Sherman: Friendster. Isaac Askew: so it's gotta have like that that's the QA bottleneck at this point, where it's it's still the more human thing. And not even just human is like manual process, but human is in human taste. This does this look does this feel professional? You know, that's the kind of also a tricky thing for telling Claude, You did everything perfect, but does it feel good? Right? There's something about it still there that's a human taste element. But did you but did you enjoy it? Did Jeffrey Sherman: I I wanna know what happens if you ask Claude if it feels good. You did this and it's right, but does this feel right to you? Isaac Askew: you have fun doing it? Surely somebody's you know I mean, we've already done that anthropomorp anthropomorphized thing. Jeffrey Sherman: but yes, so the goal, I recommend it. It's newly relevant, it's a re easy read, but it is newly relevant again because this is a time where your bottlenecks are ra rapidly changing, Isaac Askew: Mm-hmm. Jeffrey Sherman: and it's good to rethink and think about this and sort of have the meta thought of my my workflow is changing because it's not about AI, it's it's it's literally a b a book about Isaac Askew: Yeah. Jeffrey Sherman: physical manufacturing. But it is once again relevant because it's all about you know, if you optimize the wrong things, you're gonna make your system worse. Isaac Askew: I give it a read. Jeffrey Sherman: All right. Well thank you all for listening. I'm Jeffrey Sherman. Isaac Askew: And I'm Isaac Askew, and this is Never Rewrite.