رونوشت 🔗
Isaac: Welcome to Never Rewrite. I'm Isaac Askew.
Jeffrey Sherman: And I'm Jeffrey Sherman, and today we're gonna ponder AI and eternal s software projects. So the question here is, as we go through and talk about, you know, the hey, never ending rewrites and things of that will just never end and they just kinda linger and they suck resources. And also on the flip side of that, the the positive side of that where you have a project that isn't that important but it needs to get done, like package maintenance, right? So you always
Isaac: Mm-hmm.
Jeffrey Sherman: have a project open where it's like, well I need to update my packages and I'm just gonna update one a week and there will always be one a week. Sort of like in Sailors where they're always painting the ship. There's a team that's you know painting the ship and by the time they get to the end, it's time to start over.
Isaac: Mm-hmm.
Jeffrey Sherman: and so how does AI kind of change this well so AI, you know, if if let's go with the sailor metaphor example of packet maintaining your packages and updating them, right? In the sailor metaphor, you always have a team, you're just always gonna be doing it. That's just their full-time job. But with the AI, you could paint the whole ship instantly. And then not paint the ship for several months and then paint the whole ship again.
Isaac: Mm-hmm.
Jeffrey Sherman: and so how does that change your philosophy around things like package maintenance if instead of it just being like, hey, let's schedule it, put it in this the system of hey, we're always gonna be devoting three hours a month, five hours a month, whatever for maintaining our packages and keeping up to date to no, the AI is just gonna do that all automatically and it's no longer something that's in our schedule. Are those are
Isaac: Mm-hmm.
Jeffrey Sherman: those type of projects gone?
Isaac: Hmm. Well, I guess you'd still have to QA in a way or find any
Jeffrey Sherman: Mm.
Isaac: kind of automated way to prove the package upgrade didn't break anything. but yeah, I mean I I we had like dependabot and things like that that would spin up, you know,
Jeffrey Sherman: Mm-hmm.
Isaac: PRs against, you know, your code base to see what you needed to upgrade and you'd review it in the past. And I guess if you set up a good enough loop, you could have it automate that for you. And I guess you'd try to find something else to work on, right? The next thing. Hmm?
Jeffrey Sherman: But what so yeah, I mean does that but does then that project become a bursty thing where it's like, it's you would you c I guess would you if you you had this pend of, would you still continue to try and do one package a month and just always be doing it, just it's on your schedule? Or would you s try to have it be like, let's get it all done and then we're gonna be done For three months and then we'll come back and we'll do another upgrade.
Isaac: That's a good question. I think it depends on the risk of of the upgrades, right? because now we're f we know I guess it's going off on a slightly different topic, but now we're seeing a lot more security vulnerabilities pop up for the packages and
Jeffrey Sherman: Mm, that's a good point.
Isaac: dependencies of those packages. So part of you is like, okay, well, we should be probably patching every day if we're finding exploits a lot faster. And there's also
Jeffrey Sherman: That's true.
Isaac: an argument to be made to you know, constantly having things in production, small upgrades, small bumps. Is less risky
Jeffrey Sherman: Mm-hmm.
Isaac: than saving for one big burst. But if you've got a good enough QA system already set up, let's say you spin it up locally and anything related to the package should go through and test, or maybe there's some end-to-end tests to make sure you can click through everything. And like obviously the unit test integration tests, you've probably got a good AI has probably helped spin up a ton of great tests for you that are that are those type of tests. But
Jeffrey Sherman: Mm-hmm.
Isaac: maybe what remains is an end-to-end test that you have to step through and they can take screenshots and prove that. The upgrades didn't break anything relevant to any imports that used it. and if the if that setup is good enough, you could even almost like maybe intentionally upgrade the things you know would break it just to prove that it's the testing is working correctly, like it's actually breaking when you expect it to. And if it's good enough and reliable enough,
Jeffrey Sherman: Could almost go continuous deployment on your packages.
Isaac: right, right. So where you can just you're you're constantly releasing any I every day if I do like a brew update and brew upgrade, there's always a package. inevitably at least one package that upgraded today. And I imagine if you're doing that every day, you're probably de-risking it a bit. And maybe, maybe that's even the future just because of the fact that AI is finding so many critical vulnerabilities these days where you're like you almost need to be up upgrading every day instead of it being, the tech debt thing that we'll eventually get around to bumping to the next once it's into life. Well finally, you know, like that could be years. Yeah, like the in the old world and now it's like, okay, we should really get ahead of that 'cause, you know, there's some PHP versions for the recent critical vulnerability that just didn't get patched. Right. You need to be on a you need to be on a relevant one to get the the critical upgrade.
Jeffrey Sherman: Yeah. Alright, since we're on PHP, so those are the never finished projects that can never finish because there will always be upgrades. How
Isaac: Yeah.
Jeffrey Sherman: about a project that it theoretically could have finished in the old days, but it never you never expected it to. Like a refactor, so we're gonna keep with the PHP thing. Like I'm working with a system that evolved from early PHP and it still
Load full transcript
has about a thousand named functions or global functions. that functions
Isaac: Mm-hmm.
Jeffrey Sherman: that live outside of a class. And we want to get rid of them because that's just bad all kinds of bad coupling and yada yada yada. But it's not that important. Right? There's a thousand of them. Right. It
Isaac: It's not hurting anything right now. It's just ugly.
Jeffrey Sherman: it's ugly. It it creates these weird interdependencies that c that sometimes come out and bite you. you don't want really wanna do the maintenance on them. Though though that code is also the bad stuff. But because it's bad and then it's also not in a class, it like it becomes this accountability sync.
Isaac: Mm-hmm.
Jeffrey Sherman: And so in the old days, and I'm talking five years ago when I started this project, I was like, all right, well, I'm just gonna knock off one or two a week as I have time, and I'm never really gonna get to the end because one or two a week is gonna be a hundred a year, and there's fifteen hundred of these things, and that's thirty years worth of work. But I I will chip away and I'll try to make some educated guesses about what the most important ones are, and things will improve slowly and steadily over time. enter AI, and today I was reminded of this project because I had some time, and today I was like, All right, let me just kick off and I have four phases of refactorings. So it's like, do phase one refactory, get it into production, and then wait a bit, and then do phase two, and then wait a bit and do phase three and then four.
Isaac: Mm-hmm.
Jeffrey Sherman: And so it's like, all right, today it did fifty five functions. it moved them one phase forward along in my cycle. And it's like, okay, that took an hour.
Isaac: Mm-hmm.
Jeffrey Sherman: And now all of a sudden, hey, this project actually seems like I could finish. If I can
Isaac: Right.
Jeffrey Sherman: knock off if I can, you know, get this thing going and I can be going through fifty a week, then you know, within less than a year I could be done. Is that right? Yeah. Yeah, yeah, I'm sure it won't be that easy. But in theory, hey, here's a long lived project that I never really expected to finish. Now I can finish. Should I how would how do you go about feeling about it differently? does that change your attitude about a a long term refactor like this?
Isaac: I think this loosely touches what we talked about in a prior episode about is it now now d do we rewrite now in the age of AI? And we're
Jeffrey Sherman: Mm. Right.
Isaac: and we've come we're settling on the idea of the idea that it still takes time to rewrite something, even in the age of AI. And the money you're spending on the rewrite could be spent on something that's user-facing or bettering their survivability or making money somehow. Right? So This is in the same vein of it's work that we can get done with, but then what happens when you're done with it? Do you need to do it now? Same thing with the cleanup functions,
Jeffrey Sherman: Right.
Isaac: we talk about do you clean it up just because it's ugly? That's if you've got time, if you're saying you've got literally nothing better to do, then sure.
Jeffrey Sherman: Ha ha ha.
Isaac: Right? But otherwise, I can imagine the company probably has some kind of new idea or new feature or new vertical they're gonna try to tackle.
Jeffrey Sherman: Mm-hmm.
Isaac: And there's only so much juice you can squeeze out of making your system better and better and better. You could have it like theoretically, let's say you said, Claude, refactor my whole system and make it more efficient. And it goes, ha ha ha, here's your things. It's more efficient. And it's done. And you go, Claude, do it again. I want 5% more efficiency. And you could do that forever and spend infinite money trying to do that. But at some point there needs to be the the part where you pause and go, Do I clean up the code base here? Do I want to. Do I we say never rewrite, but do we want to try to rewrite all this for what reason? are describe to me the problem instead of just saying, I think a lot of times we're like people use AI to go find problems. audit my code base and clean
Jeffrey Sherman: I do that all the time.
Isaac: up the indeficiencies, right? Because we're we're we're telling we're not starting with we know what the problem is, we're just going, clean it up for me, right? So
Jeffrey Sherman: Yeah.
Isaac: instead, and it it can it gets better and better at that. But again, that that's just an infinite money sink. You could always try to find some facet that could be slightly improved. And so at some point you have to step back, I think, and go, okay, I think we've done enough improvement even in this section over here. We can spend our tokens more effectively by building this new feature that customers have been dying for. Right. And it it takes it's gonna be one of those balance things, right? Because Now engineers finally can tackle the tech debt they've always been begging us to tackle,
Jeffrey Sherman: Right.
Isaac: you know. And then once you do that, what do you do? Tackle it again, tackle more. There's always a plugin to upgrade. There's always a package to upgrade. At one point, at one point do you go, okay, well, we still need to build things instead of just maintain.
Jeffrey Sherman: Right. Another way to put it, to describe what you're saying is keep the time box. Right. If I was willing to spend a couple hours a week or an hour a week, a couple hours a month on this refactor, which was useful but not that important, with AI I should still spend an hour or two and now I'd I just might actually get it done because A AI is gonna do 'cause this is a very simple refactoring, like mechanical, so it's gonna It's the kind of thing where AI is gonna give not just a ten X, but here it's giving me fifty X performance. Because it's a very I've broken it down, it's a very mechanical task. And so it's like, but don't go crazy, just
continue to use an hour or two here and there. Okay, now now's the tricky one. What about stopping projects like l you've got a project that's not done?
Isaac: Mm-hmm.
Jeffrey Sherman: and the boss comes to the boss has got some shiny new project. And you're like, Well, but we haven't finished this old project. This is the shiny object syndrome. Predates AI, right? You now you can have so many more projects and with AI there's so many more ideas. How or can you does AI change anything about the argument of, hey, I don't want to start any new projects unless we should close end the old ones?
Isaac: Well, it makes it trickier to defend because engineers, always saying we don't have enough time, and no, magically we have the 10x engineer because of Claude's ability to help us do that. I think you still want to push back and make the argument that, the context swapping between the two is still taking up some time, even if Claude can manage a lot of the context for you. Right. but I will I think there should be a little bit more pushback on the products that are pitched.
Jeffrey Sherman: Mm.
Isaac: and this reminds me of when when ch Chat GPT first came out, everyone, was, using it to do funny things explain Taoism in the form of or using the language of Snoop Dogg or something like that. funny funny.
Jeffrey Sherman: Yeah, yeah, that I I was literally thinking, didn't somebody have Snoop Dogg write a sonnet in Shakespearean sonnet chance?
Isaac: Exactly.
Jeffrey Sherman: It's just like and they'd be funny.
Isaac: Right. So in that early innocent era of Chat CPT,
Jeffrey Sherman: Ha ha
Isaac: well w you know, our company was like, What what can we the company I used to work for was like, Well you know, what can we use this for? And I was like, let me explain it what my company does and have it generate some product ideas for me. And it generated twenty product ideas and they were all just terrible. They made zero sense. Right? Now, today I'm sure maybe they'll they've gotten better, like It'll pull in competitor information, other
Jeffrey Sherman: Mm-hmm.
Isaac: things that have been pitched that didn't work, or it pulling in like the changing political climate, or things that are related to grants that got canceled, so that doesn't make sense to go in the avenue because the government helped subsidize this thing. All kinds of reasons, you know, that the products could float or sink. So it can do better, but it still has that fatal flaw of like promising you the world of like, here's 20 amazing ideas. Nope. you you're right to question that, And here's here's all the great things. You know, you've noticed an untapped area here, Isaac. Well, what? I'm the chosen one, right? It promises you
Jeffrey Sherman: Ha ha ha.
Isaac: these things, right? And so you end up spending all this time with these ideas, and it'll give you so many shiny objects. And you don't kid yourself, the product people at your team are totally using Claude to to validate this
Jeffrey Sherman: Yes.
Isaac: as well, right? You know, so now it takes a lot more time. You can in the same way. you can spend all of this money constantly upgrading forever, you know, for for not much juice worth the squeeze. You could generate
Jeffrey Sherman: Mm-hmm.
Isaac: a thousand product ideas, 99 of which are just useless. No one even cares about, but that sounds exciting and fun. And then you're you're still building a from your perspective, like, what if we did this? People would love that instead of starting with a problem, right? And so you
Jeffrey Sherman: Mm-hmm.
Isaac: can spend just as much money, you know Building widgets after widgets attached to your system that do every little thing that no one cares about. So I think to to the to answer your question, does this change how the engineer should finish one project before another? I think in that sense, maybe the engineer should push back and say, Let's finish this one first while you vet your idea, and maybe let's get a little more context around your new idea, the new shiny object that you want, and why you think this will work. because engineers too, you know, that context may matters a lot, right? Because in the new world, the engineers should be interfacing with those teams to understand what they're building and why. Otherwise, why are you even talking to an engineer? Otherwise, just give Claude to the product guy. You know, the the point of the engineer is to provide that, you know, that glue in between and interface and you know, talk about what's reasonable too from an engineering perspective. And I think that. that is the area you'll spend more time in. close the loop of your old projects, but also provide more information for what an engineer needs to be doing in the new AI world of AI engineers.
Jeffrey Sherman: You know what I realize we're saying, Isaac, we keep coming back to is the thing we said have said many times, which is AI
Isaac: Mm-hmm.
Jeffrey Sherman: doesn't change anything. It just makes everything that you do faster.
Isaac: Yes. Yeah. That's the main thing. Yeah.
Jeffrey Sherman: and so it doesn't change anything about shiny optic syndrome. It doesn't change anything about long running refactors, it doesn't really change anything about package management, it's just you could do it faster, but still it's an infinite times. Still costs money.
Isaac: But it still costs money and you can spend money faster.
Jeffrey Sherman: Yes.
Isaac: So should you? It it really still comes down to what do you build and why are you building it and good decision
Jeffrey Sherman: Yeah.
Isaac: making and good communication. In fact, that's even more important. Because all it takes is one enter key and you've spent twenty grand an engineering cost building nothing or bumping packages for nothing. This is expensive.
Jeffrey Sherman: Right, yeah, yeah. AI AI is the new runaway AWS.
Isaac: Yeah. absolutely. and even scarier in the hands of the Rome people. Yeah.
Jeffrey Sherman: Yes. I'm just gonna burn infinite tokens. And
Isaac: Yeah.
Jeffrey Sherman: just like AWS I don't know if they still do that. I haven't heard any of those juicy stories lately. years.
Isaac: Just because you laid off ten percent of your engineering team doesn't mean you can't spend just as much money as you saved on
Jeffrey Sherman: Yes.
Isaac: a bad bill.
Jeffrey Sherman: Yes. All right. So does AI change anything? So seems like the answer is no, it just makes what you do faster. And so if you do it right it's better, and if you do it wrong it's worse. But keep your eye on the ball, keep your eye on the business. Thank you all for listening. I'm Jeffrey Sherman.
Isaac: And I'm Isaac Askew, and this is Never Rewrite.