TRANSCRIPTIE 🔗
Isaac: Welcome to Never Rewrite. I'm Isaac Askew.
Jeffrey Sherman: And I'm Jeffrey Sherman, and today we're joined by Robbie Rahm, a longtime refactorer and founder of Dully, to talk about refactoring, his approach to refactoring, and how AI is bit how he's layering that onto AI and how things are changing and not changing. Robbie, thanks for coming on the show. glad to have you. why don't you start by introducing yourself?
Ravi Ram: Sure, my name's Robbie Ram, a longtime listener. and I again it's interesting to hear your voices because I usually have you a little
Isaac: Yeah.
Ravi Ram: on the one speed, 1.5 speed. been developing for over 20
Isaac: Nice.
Ravi Ram: years now, mainly.NET Shop, mainly some local government contracts, city type of contracts that we do with. And now we just have a a depth of clients. I I came into refactoring probably about 10 years ago. when I just got some really nasty classic ASP code if we remember that from back in the day. And I used to do that. Yeah.
Jeffrey Sherman: That was my first job. My first professional after college job. I was d working like ASP three.
Ravi Ram: Yeah, yeah, I I I I started off with Classic ASP. So I'm one of the few dinosaurs still around that if you actually Google Classic ASP Expert, I I c I I come up on some of the searches. It's very interesting.
Isaac: Nice.
Ravi Ram: so with Classic ASP, probably about ten years ago a lot of my clients started migrating over to dot net from classic ASP. you know, even using Access Database, you know, all the way up to SQL. So I ran into just just headaches. and I found myself enjoying it, like actually getting into the mud of the dirt of the code that's legacy software. whereas the other developers, when I join a team, they'd be like, give it to Robbie. Like he he loves this stuff,
Isaac: Mm-hmm.
Ravi Ram: give it to him. And I did, I I found a passion of like just taking some nasty code and unwinding it, figuring out what it does, and then extracting it. and I remember watching a a YouTube video by Louel Falco and Woody Zil Zuller, Z-U-I-L-L. I think it's called practical refactoring. It's on YouTube, and I can send you guys a link later. And they sat
Isaac: Sure.
Ravi Ram: down, and what they use is something called slice and peel, which like somehow stuck in my head. And so I started doing that with old legacy ASP code. No matter how nasty it was, how bad the front end was, I would just take a very, very small piece, maybe 10 lines, write a test for that, extract those 10 lines. And let both run a little bit to see what happens and then comment out the 10 lines. And then wow, it worked. And then take those 10 lines, put them in the function off to a service somewhere, and just watch the code work. And I slowly did that. It's tedious work, it takes time. you know, I tell my clients sometimes like a page of nasty classic SP, could take me a week to just move pieces out into a service that's stable. We're not done yet, we're just moving. small
Load full transcript
little slices and peels out. And I found myself doing that more and more again. And I I I just loved it. It worked great. It wasn't a major rewrite at all. It was just a small little teeny weeny slice that was moved out.
Jeffrey Sherman: Awesome. So this be the standard take a little piece, extract it, a pure refactor where it no functionality's changed, and then you know going with the lots and lots of commits or and lots and lots of releases, and then you've got the making the hard thing easy, because now you've refactored it, and then do the easy thing.
Ravi Ram: Yeah, exactly. And and the cadence that I got into was releasing at least once a day, if not a couple times a day, getting those PRs out. there's a book called Tidy, and I think I have it back here on my shelf by Kent Bennett.
Isaac: Mm-hmm.
Ravi Ram: Yeah, a and that that one explains it very well. I I again we didn't we didn't do any business logic changes. It was just code, moving code. Literally, I just call it that. Let's just move this code. I don't want to scare the business owners or You know, the lead developers, hey, we're just gonna move this code out. And after, you know, a month or two, you're like, wow, this looks cleaner, it's easier to use. If we want to add some business, additional business logic, now it's a small piece of the pie. And and I found that worked incredibly well to do refactoring. And again, I I love that piece. So whenever we the team got into a nasty piece, they're just like, Here, Robbie, refactor this. Before
Isaac: Mm-hmm.
Ravi Ram: we even add business logic or do anything to it. But that that cadence, the release cadence was very important to prove the concept worked, right? If we waited a month to release a hundred small refactors, that that's death. Every day we could push something out that was a very small change. If it broke, we knew exactly what broke, where
Isaac: Right here. What's the probe?
Ravi Ram: it broke, the 10 lines, if so, what broke it. And it was super easy to revert or fix. and that's the way I I I really tried to get it. And that's a whole nother headache is that release pipeline. you know, some solutions didn't build the first time I got there. They didn't have any CI C D, right? I'm sure you guys run into this. And so that was a whole nother project. Can we release daily or weekly? The
Isaac: Right.
Ravi Ram: answer is usually no, you know. And then it's like, okay, we need to do that before we do anything else. And and I know business owners don't want to hear that, but really to protect me as a developer and them.
Isaac: Yeah. Mm-hmm.
Ravi Ram: should have a cadence of that or a clean pipeline that does that.
Jeffrey Sherman: Now when you were doing this work, 'cause 'cause some of the things the timelines you were saying of like, you're doing a month of the peer refactoring, was this as a full time employee or was this as a contractor consultant where you're coming in with a team to work on project?
Ravi Ram: So I I I'm
a consultant, so I don't come in as a full-time employee, I come in as a consultant, and whether they budget one developer or four developers at twenty, thirty, forty hours a week, that's how we break up the project. so it all depends on what the budget is for the client. And and again, they know I'm coming in to work on nasty, bad code. That's kind of my wheelhouse, that's what I
Isaac: Mm-hmm.
Ravi Ram: advertise and what I like to do. and it could be simple as, hey, our password resets hasn't been working for for a year, right? Like it's simple as thing. Customer service password reset doesn't work. It's flaky. So I'll just go in and say, okay, let's just click the button and see what happens. And then we go for literally just go from there. So yes, as a consultant,
Isaac: We don't this.
Ravi Ram: and you know, depending on what the what the client wants.
Jeffrey Sherman: God, I I I wanted so wanted to get distracted on this. How could they possibly not
Isaac: You are Okay.
Jeffrey Sherman: have password resets for a year? But let's keep going. Isaac, sorry.
Ravi Ram: it it's a true story. I could name the client on this call and if there are developers
Isaac: Yeah.
Ravi Ram: there are listening, they'll say yes, that is the
Isaac: Yeah.
Ravi Ram: true story. And it's a huge company as well. You know, multi-million dollar a lot, lot of money coming through the company.
Isaac: Yeah, I was just gonna say that you're you're like a coding brother. like everything you're saying, like I I relate to exactly what you're saying with I I was the PHP guy at a few different companies where like they hated PHP and every time there was a problem that came in, like everyone else had already they would they were using some new modern stuff in TypeScript and React and they loved it. Whenever the had the old stuff they wanted to fix, like, it's PHP, that's that's Isaac, let's throw it to him. The same thing where it's just like old code, dig through. Figuring out how it works piece by piece. that whole flow, I'm obsessed with it's really fun for me. And I can hear from the way you're s you speak about it that that's the same kind of joy you get out of that. So I I immediately recognized you as like, okay, this is my people right here. And the same thing with
Jeffrey Sherman: Yes.
Isaac: the company. I did the same thing with the consulting on the side. And well, I guess it's your main business, but I do some consulting on the side that's a similar thing where that our we come in and refactor. scaling issues or point problems like the password resets. So I'm just you super relating and vibing to to your story right now is all I'm saying.
Ravi Ram: Yeah. And and I do want to say, like, you know, if you're listening to this and you're like, this is crazy, why would you want to do this? I got a lot of bruises,
Isaac: Ha ha ha.
Ravi Ram: bumps, you know, you know,
Isaac: Yeah.
Ravi Ram: it's it's been a long journey to get to this level of like, I enjoy this, right?
type of work. It's it's not that I just woke up one day and said, I I will love refactoring. I just I do enjoy it, but it took me a long time to get to a point where I'm competent, I have a flow, I have a process that that has been successful. That I've been using and actually teaching other juniors to use. And I and I I enjoy that part too. Like, hey, let's let's both get in it together. Let's screen share. Let's let me show you how I do this. And it's it's very simple at the end of the day. Like the concept I just said, I don't know why people are mind blown when I say, yeah, let's just take a few lines and move it, see what happens. Like, whoa, that's crazy.
Jeffrey Sherman: Yeah, that goes to we have similar I I'm also a brother with a similar philosophy of and that's where I tried to come up with new words, so this is where we've got like the thesus shipping of we're gonna replace everything in it, but it's gonna be exactly the same, so it's the same thing, but not. Where
Isaac: Yeah, that goes to the similar blocks. We're gonna replace everything in it. Exactly the same.
Jeffrey Sherman: so and I have also taught classes and you know worked on pieces of code together. It's like, alright, I d I don't care what it is, refactor something. y I've been dealing with a procedural PHP system for a while and we would have functions that were a thousand, two thousand lines long that had grown organically and I'm I'm like, alright, I'm here's for here's step one. I've taken this whole thing and I'm gonna stick it in a class and the function's called do everything. And that's step one. We're just gonna make sure that that that didn't break anything, and you'd be amazed how often that broke something. And then alright,
Isaac: That's step one. All right.
Jeffrey Sherman: and then from there we're gonna break it down. And then hilariously, years later I've gotten being like, Why the hell did you create a function called do everything? It's it's a rapper, man.
Isaac: It's a rapper.
Ravi Ram: It is. It's it's literally you know, that that extraction. Sandy Metz, I don't know if you've heard of her talk before. She's
Isaac: yeah.
Ravi Ram: a Ruby on Rails back in the day, but she had these guidelines like no classes can be more than like 20 lines of code, no parameters can't be more than four parameters, otherwise make it into a class or an object that comes into there. And so I I was very dogmatic in following her, but it didn't work out for clients. Like, you know, I go, all right, 50 lines is where our threshold this time, next time maybe 30 lines.
Isaac: Yeah.
Ravi Ram: But I do have a you know, and we talk about AI a little bit, I do have a skill that will check for those type of things when I you know, actually am using AI heavily in the refactoring, which has just been a godsend. and so I I do have these standards that we developed and that I bring in to a team. So if I'm brought into a team to help out, I try to establish known standards for me that
that are industry known, but kind of like very simple four things. Hey, how long's this class? Like you said. Jeffrey, you know, what's the longest class we have or page we have? You know, four thousand, forty five hundred lines of code. Okay, that's probably the God object as they call it. This is where everything happens. The business logic is here. Let's let's take just one little piece of that and move it. You know, and everyone's like, no, no, no, don't do that. You I'm like, we can't, just slowly, slow.
Jeffrey Sherman: Yeah. People are that is something that I have encountered a lot is people are terrified of touching those objects.
Isaac: Well then yeah, let's get into your process because that's one thing that I've I've noticed. Like I I feel like in discussing this kind of like, this is how we we break things apart. There's some pieces of that that have been sped up so much by AI. And if you put guardrails in place, it can jump quite a few steps that sometimes I'm like, man, I was really looking forward to this process
Jeffrey Sherman: Yeah.
Isaac: I like doing that AI just jumped ahead and actually did a pretty good job, and they don't need me to do that. the the part I liked the most that was the most fun is just kinda like jumps ahead and there's like the testing phase and the QA phase. Like what's what's your experience with that? Has it kind of like like hyper speeded that for you or is like what what is your current process, I guess?
Ravi Ram: So about nine month my nine months ago, let's say, is when I really leaned, just like, you know, leaned into it, right? Obviously two years ago, 40% accurate. Now we're up to like 90% accurate
Isaac: Yeah.
Ravi Ram: with proper structure, coding, standards, all
Isaac: Right.
Ravi Ram: that. So now what I'm doing is you know, just the other day I did a you know, I'm working on some crazy Azure Functions app, and it was written by a junior developer that's really messy and he used AI to do it. It's just, just not good. It works. You click you you You trigger
Isaac: Mm.
Ravi Ram: that function and it does an email and does reporting and does everything. so my process usually is is to tell AI, hey, here's a standard you know structure we have. We have a repository, which does the database calls. I get very simple stuff. We have a mapper that maps to some sort of service that then will inject that into a UI layer that will do something done, right? So three or four kind of the onion architecture type
Isaac: Mm-hmm.
Ravi Ram: layout. And so I just have a skill that says, hey, let's create a repository and let's move all the SQL commands into the repository. Are we using in my world Entity Framework or Dapper? I'm moving to Dapper only now from Nity Framework. So I will only do that, right? So I'll say, hey, work, I'll I'll usually point it to a page. So let's say it's a customer page. I'll say extract all repository database calls to a you know the repository pattern and create that only. That's all I want you to do. And I'll watch it and I'll review that PR or review the code changes. And I only do the one page. And when I
Isaac: Mm-hmm.
Ravi Ram: feel comfortable that it knows the current code, because it's gotta kind of figure out how nasty the code is and what we're dealing with. And it will make mistakes. It will, you know, pull some UI stuff all the way in the repository. Just because the way the code is currently written, it just did it. So I'll have to go in and massage that skill that I have specifically for the client. So now I've learned a create a you know never rewrite dot md file which is hey this is the client
Isaac: Mm-hmm.
Ravi Ram: but I still using my refactoring skill for the repository. But this client is using this weird pattern. So now I need you to go ahead and load my repository skill, but also look at this client specific that we found these issues.
Isaac: Hmm.
Ravi Ram: And so that's the way I've been using it. So it does take me a little bit of a ramp up time to do one or two pages until I figure out, okay It's it's went from 70% to 85%. We're at 92%. And usually anywhere high 80s, that's a a competent middle lever level developer. And I'm happy with if we hire a mid-level developer that can do 80, 90% of the work cleanly. Like I'm done at that point.
Isaac: Right.
Ravi Ram: Like I don't need a 99% accuracy. I don't need an architect level. We got stuff to do a g you know, even higher than a junior, even a junior developer, I would still take the code ref, you know, extract it. But let's get it to that 80, high high 80s, 90%. So that's the way I've been doing this, is that slowly, and then once all the repositories are done, and again, there's unit tests around this, you know, we hit the page, have QA hit the page, hit refresh, do the customer order still appear or not? You know, silly things like that
Isaac: Right.
Ravi Ram: that people kind of forget to do. and that's kind of the pattern I've been using for all the layers, one piece at a time.
Isaac: So is it fair to say like let me know if I heard this right. You've got like a parent standards file essentially that you start with and then you as you look at the code base that you're working with and see how nasty it is, you essentially make like a substandards file that's like use the main standards I have but have them modified slightly for this particular client.
Ravi Ram: Yeah, it's actually a skills folder. Within that skills folder,
Isaac: Mm-hmm.
Ravi Ram: I have a repository pattern skill. Outside of the skills
Isaac: Okay, yeah.
Ravi Ram: folder, I'll have a client file called never rewrite.md. In that I will have very specifics about the repository. So mark down pound pound repository, you know, known issues. Then in there I'll put
Isaac: Got him.
Ravi Ram: maybe 10 bullet items that I know that when I run my specific skill, because I don't want to modify my skill. Unless it's a major issue for all my clients that I'm running into. But if it's just
for the specific client, so that markdown file, the never read out mark markdown file, travels with the client, with the repository, gets committed so that another developer can pull it down. That file is then wiped
Isaac: Got it.
Ravi Ram: out when I re-add that skill to client two, right? And client two, let's say it's whatever you know, example.com I'm working on, they'll get their own markdown file. And the repository might be clean. So I might not have an entry for repository, but the view model might have an entry. Ten bullet items I've got to look out for. So that's the way I work. So it's out outside of the scale file in the root. Well, I have a dot agents file now. I don't do dot clot or dot cursor
Isaac: Mm-hmm.
Ravi Ram: anymore. I just have dot agents because I was getting madness because I was switching LLMs and harnesses all the time. So I have a
Isaac: Yeah, totally.
Ravi Ram: dot agents file now. And that dot agents file is where I keep all the, you know. kind of the standards, prefix stuff and then the client specific stuff. Doctor, does that hopefully
Jeffrey Sherman: Qu question for you.
Ravi Ram: that answer that?
Jeffrey Sherman: Yes,
Isaac: Mm-hmm. Yeah.
Jeffrey Sherman: so one thing that I'm now curious about, because we talked about this in a previous episode, was if you've got your standard agents stuff and then you layer on each client individually, have you had problems yet where the agents are pulling in stuff from different clients and crossing people's codes yet?
Ravi Ram: no, I because our projects are you know very strictly defined in our so sometimes we'll have a VM just for a pro project because of sensitive data and things like that. So they don't even know these other unless I tell it, hey, by the way, this Git repository with this Git credentials, you can go see this. I don't. They're they're I very isolated. They don't know about each
Isaac: 'Cause they don't even know each other. Unless I tell it eight, by the way, they're I'm very I don't think they don't know.
Ravi Ram: other. They've got their own, you know, git either they're in GitHub or Azure DevOps, wherever they're. stuff's located so they don't know anything. We will have to manually do kind of like a skills update file where I'll do like on my hard drive, hey, here's our skills files, here's a current skill file, kind of look at it. Let's copy over stuff if we need to. It's very rare. Maybe once a month do we update our skills? It was regularly because we were learning as we were going, but we have a pretty good standard. I'm I'm, you know, the everything's getting better, so we're trying to prune down the skill files. They don't need as much information with the smarter models. So they don't have to be as fat and knowledgeable, they can be a little leaner, but we're still very happy with
Isaac: Mm-hmm.
Ravi Ram: the standard. And I found that's where when I run into a dev team that's using AI, is that when you have messy code and you tell AI to rewrite it, it's gonna rewrite it messy code. It doesn't know any better. It's taking your example. But if you have skills and examples within those skills of here's a clean repository architecture that I want you to follow, then it will go, okay, I I can get there, 70%, 80%. And again, that that line is this is client specific. They wrote this in a weird way. They're doing some
Isaac: Yeah.
Ravi Ram: crazy select statement that is not standard, you know. I've seen all kinds of crazy joins and stuff that just doesn't work out right. So that's the way.
Jeffrey Sherman: So I'm curious, because one thing that I have noticed, especially kind of with the onion type stuff of the larger a chunk, the the more layers of an onion that I try to slice in one go, the less it follows my agents and skills files. Where if I say, okay, do this, you know, you like you said, move all the stuff into the move all the database stuff into the database layer. It it generally does a good job. But if you try to tell it, okay, do all the refactoring.
Isaac: So here like two things that one believes. Well, one weekend I burned three, four hundred dollars because I let it run overnight because everyone's like
Jeffrey Sherman: it just is a mess. I I don't know if you have also seen them. Like I I can give it like here's my ten things, do do step one and then I'll release it and then do step two. But if I tell it do all ten steps, just it's a mess. It doesn't it doesn't work.
Ravi Ram: It it's absolutely a mess. And I've got into autonomous looping as well. one weekend I earned three, four hundred dollars because I let it run overnight because everyone's like, hey, just tell
Isaac: heavy just.
Ravi Ram: it to go. And I'm like, Cool, I'll go to sleep and it's gonna be done, you know, a month's worth of work. It the absolute mess of a nightmare, plus money's out of my pocket. It was disaster. So I I have not found a clean way to do this. If I do it, if I run a loop, which I have been running loops now and they've been working fairly well. They're very isolated to just the repository layer, right? The data access layer. And only to move the SQL commands out. Don't do anything else. Just let's move the SQL commands out. Because I mean, I'm sure we've all seen crazy stuff in code where there's all of a sudden that SQL command that's, you know, somewhere in a page that should not even be there. so that that's kind of the way I do it. So I I have tried running it on a project, like, hey, here's my eight skills from repository all the way to the view. I we use do react a lot. So here are the React components. This is how I want you to stack up React, Redux, all that stuff. Go. Like, you know, that's the dream, right? Like everyone says you just go and it's gonna work. no, it's it's it's a nightmare, it's horrible. The PRs, thousands and thousands of pages and lines that you gotta review. And I'm I still want to review lines. I'm getting less and less because I'm trusting it in certain
sections of the code.
Isaac: Yeah.
Ravi Ram: I know it's doing a good job. but no, I have not found a clean way of doing that. Maybe one day, but not right now.
Isaac: I think the closest I've gotten to that is using the slash goal command and then having it like if I needed to do 10 things, the part of the goal says do the ten like it writes them to an MD file that the the assessment of the ten things that need to get done. And then part of the the goal command is to review between each one before proceeding to the to the next one. Then once you're done with all ten, ensure that how you've done it meets the criteria of all ten. And that's then only using the slash goal. otherwise it runs into that same problem that Jeffrey's talking where both you were talking about, where it for some reason, if I take it one at a time, it's fine. But if I tell it to do 10 of them and just just do it, I'm gonna go to lunch. I hope this
Ravi Ram: Yeah.
Isaac: is done by the time I get back. And it's just like, did you did you finish everything? no. You're right for pointing that out. And those distinctions
Ravi Ram: I have so many of those snippets I put
Isaac: matter.
Ravi Ram: Yes, yeah. I have so many of those like, you're right, you told me not to commit. I did. Sorry. I'm like,
Isaac: Yeah.
Ravi Ram: Yeah, I haven't even reviewed anything yet. Well, you committed everything, like the pipeline's running, what'd you do? You know, so I and I do have very strong
Isaac: And I've still had some
Jeffrey Sherman: Well, that's interesting.
Isaac: go ahead.
Jeffrey Sherman: Why why'd you tell it not to commit? I'm like a commit hog. Like, yeah, commit, commit. Every the commit everything every thought you have and whatever, it's get. I'll just not merge it.
Ravi Ram: I I have a very strict rule that says no git commands that will do do any writes, right? So I I I'm still old school. I want to see the diff
Isaac: Mm-hmm.
Ravi Ram: in my, you know, VS Code or Visual Studio, look to see what it changed, approve those pages to get committed, then I manually hit the commit button. I I am I am not trusted enough to just go, yeah,
Isaac: Yeah.
Ravi Ram: when you're done, commit. I I I know obviously I've got Git and I can revert everything. I just don't know why I still want that control there. And so yeah, and you know, we can get into more of how our workflow is with sessions and and like you said, like if I leave for a walk and come back, can I continue tomorrow on what I left off with? So we can probably get into that another day. But as far as you know, the refactoring, that's the standard process where you've I I've developed now and then my team has been using is just one layer at a time. my one of my developers is really good with React, so like he kind of lives in that React land. So when we get from the layer From database all the way, you know, down at services, down to ViewModel, down to React. Like he kind of lives there. And I tr I'm trusting his skills to do their job and they're great. Like I could say create a customer list page using, you know, Tanset Query with datatable.js with React. And like it's it's 80% good, which is 100% Robbie. I'm not a React guy. So 80% good React code
Isaac: And six sixty percent a hundred percent wrong I'm not a react actor.
Ravi Ram: for me is like, this is crazy good. Like it does everything for me. but same thing with him. He's not the back end guy like I am. So for him to get a API with the data layer with the query down to the it's it's magic for him, you know. so
Isaac: Right. So we're we're both working together.
Ravi Ram: we're we're both working together in this and it's it's coming out really well.
Jeffrey Sherman: Cool, so what's the impact that you've seen? like so you're do having the AI do the onion the the thesis shipping of of all of these things one at a time. How is that impact, like is your have your timelines shrunk?
Ravi Ram: Our timelines have shrunk dramatically. So something that would have taken a week can take four to six hours. maybe let's say a full eight-hour day with QA testing, but that's crazy, right? I'm not talking about coding now. I'm talking about like ready to be released.
Isaac: What do you think about sixty four thousand? maybe let's see up before what we hour days. That's pretty true. I'm not talking about coding count, I'm talking about like regular.
Ravi Ram: but it it takes a time to get there, right? Like my plumber shows up and I've got a leak and it's 115 bucks an hour and he's done in 15 minutes. Right. I I still gotta give him the hours worth of work that he did because he's got 30 years of experience, has all the tools and all that. But it is kind of, you know, like then do we offer the client more work for what they contracted out? Do we do we just say, yeah, we our tools have gotten better?
Isaac: I I just look at it for the hours for support that he didn't set certain experiences at all and all that, but it is kind of not essentially offered a fine network for working contract out. just like, yeah, we're talking about
Ravi Ram: So this is kind of a I don't want to say a dilemma, but just something that I've been talking to other owners and other people that are billing, you know, whether it be bulk bulk hours, we you know, buy X number of hours from us or hourly, where are we at with? Can we do more work? Can we make it better? Should we clean the code? Should we make sure they're everything else is running? The pipelines, all that correctly. maybe it's that type where we move into more of a, you know, not only do we do the code, but we clean the code, we do the code, and we make sure it's working and publishing correctly for that
Isaac: But that
Ravi Ram: bulk hours you're you're buying from us. so again, it's it's new. This is all new, and you know, and my employees too, right? So I pay them 40 hours a week and They're done with the task in, you know, 10 hours, like he he goes surfing. I'm like, hey, hey, I'm I'm
I'm good with that. Like I that's great, you know, but how's this gonna work long term over the next year or two? And I think everyone's kind of dealing with
Isaac: You know, ten hours like I'm like, Hey, hey, I'm I'm I'm good with that. Like I said,
Ravi Ram: that dilemma right now is well, at least as a business owner billing clients, we're very ethical in what we do. What what do we do? Do we say we're done early because of AI? Give us more work, and maybe they'll say, Great, yeah, here's a lot more work. Everyone says there's more work to be done than there's actually developers. Wow, that I could get a little little bit less and less. do we spend more time writing the skills? Do we spend more time, you know, ha honing our craft down? I I'm I don't have an answer yet. I mean, maybe in six months I'll have a better answer for you. but you know.
Isaac: Yeah. There's one project that I've been working on. I've been working through another company that's doing this, contracting out like different AI workloads for for companies that don't have like a tech stack or like a tech team, but they still could benefit by automated processes. And what how they've modeled it was like your projects we've agreed on a a max amount that we're willing to spend on this project. And then you just send us hourly billing. on everything leading up to that. And we kind of approve like in each with each increment. I forget the the increments that we're using at the time, like half an hour or whatnot. you explain what was done. And we ended up getting pretty much everything for the first iteration of their app built in like less than three hours of billable time. I think and I think an hour and a half was just meetings to understand what they needed. And the rest was just agentic, this is what they need. And we actually like Created personas from all of their requirements. Like there was three people talking. So if each person said, I wanted this, this, and this out of it. We I put that as part of like an invariant, like it has to support these people in the MD files. and then just submitted the billing. Like so far, it's like, okay, three to five hours of billing. I think we're done. And then we still have a huge max of what they're willing to pay as far as I think the project itself was like 25,000. And so far we're just billing for five hours. And then we're like, okay, well, do you want anything else? Or are we are we done here? Do you wanna own this? And so that's but we're still trying to figure out like how do we do this? How do we do the handoff? Do we own it? Because we're making changes to it. And they probably can't because they don't have a tech team. Don't know yet. But that's where we're at too. We're like, we we don't we're not gonna bill them twenty five grand, you know, cause we don't need to. Yeah.
Ravi Ram: I it's yeah, in my mind it's I some people say it's not in my mind it's kind of unethical, but other people say, Hey, you you've taken you twenty
years to get to this point. Bill what you can, you know, for your time. So there's there's there's that.
Isaac: Right.
Ravi Ram: you know, and our internal team, so let's say my my project managers and and they're like using Chat GPT workspaces now, we kind of use that as as our company. And this last client meeting I went, we had it three months ago. We uploaded all our notes. We uploaded the client's documentation. One of my project managers just spoke for half an hour on what the client wants with this QR code shipping tracking system. And within half an hour, we had a product spec, which we gave to our developer. The developer then went in there and said, Hey, this is the database scheme I'm thinking about about inventory tracking, warehouse location, shelf A versus shelf B and all this stuff, and just spoke for another half an hour. We got the most amazing spec doc that we then plugged in to
Isaac: Mm-hmm.
Ravi Ram: at the time we were using Claude and said, Hey, write a complete phase project with specs, with database schema. This is our pattern that we use, repository to view, and we're using React. It it spit out this most beautiful document that we fed back in
Isaac: Yeah.
Ravi Ram: and said, build the database schema and the repository. And within like two hours. We we had it done, like just that piece. And I was like, this is a month, like this is a crazy amount of work that we're getting done and just people's notes being in the same place put together from the low level, you know, low-level you know, data entry, kind of like, hey, this is what the client wanted. This is kind of their website.
Isaac: Yeah, I don't know what it is.
Ravi Ram: Here's some HTML to a senior developer with database schema knowledge. And and we're we like just said here, go for it. And we still update that document today with what we've
Isaac: Yeah.
Ravi Ram: done, what needs to be done. It's pr it's pretty amazing just as a business, right? Like not just coding, but what we can do with with with documentation as well.
Isaac: I think I did something similar with this project, in that we recorded the call and then we exported the transcript of that call and I said, Okay, as the the people who are the product owners, that's the word of God. Never go against what they want, because they are the ones using it. When I ask you to do something AI, don't take me literally. If you know a better way to do it, fight fight with me, but don't fight with this invariant list of personas here essentially. So like I like the idea of using like what they The actual meeting and the notes and confluence documents and Jira stories all is a big aggregate to feed into what needs to be built. Jeffrey, you were gonna say something there?
Ravi Ram: And this was our first yeah. sorry, go ahead, Jeffrey.
Jeffrey Sherman: yeah, no, so I when I hear stories like that, I I always wonder and so this is the follow up question of it feels like if you were going slow, this would be a very waterfall thing that you're describing, right? You you had a spec meeting, then you wrote a spec, then you had some code, and then you take that and be go back to the thing. But because of AI it's all sped up and compressed. So I'm wondering how
Isaac: Mm-hmm.
Jeffrey Sherman: like when you first presented that to the client, the you know, a after you spit it out and get only five hours of worth of work, what was their reaction? Was like you guys are way on
Ravi Ram: So what we did is we go to
Isaac: So what we do is we
Ravi Ram: Figma first with our screenshots and layouts of the pages and we present that to the client. And it Figma's again, they've got a whole AI component in there called make.
Isaac: Mm-hmm.
Ravi Ram: So you can take your spec doc that could be a very nerdy spec doc and put it into Figma and say, create tables, clickable, sortable, go into a detail page, show this checkout flow with the QR code or something. And it it so My lead developer will, project manager will actually then send that link to the client and get on a Zoom call and say, How's this look? We haven't coded anything. It's got mock data. Click through it. And that's when we get the client feedback. Like, that's good. you guys got that. That was a you know, like like you said, Isaac, just something they said in a meeting and we should start recording those. We were on site, which is
Isaac: My re developer will probably manager will actually then send that thing to the clients and get on a zoom log and say, let's work we haven't turned anything. And that's where we get the fine three times. that's good. we got that like a something they said in the key is currently what's
Ravi Ram: a rare occurrence for us, but we're actually local company on site. I should have just turned on a little recorder, you know, like an interview, like you know, doing some CIA interview or something, hit record.
Isaac: Let people know they're being recorded too.
Ravi Ram: Yeah, yeah. but so so
Jeffrey Sherman: Yeah, you don't to surprise anyone.
Ravi Ram: so Jeffrey, we we did that and then presented to the client. They gave us feedback on on that. So the before we wrote again, wrote a line of code, had AI write a lot of code, we had a Figma mock up because that's kind of the flow we've been we've been used to. And with Figma make, it's making dumping that spec doc in there to get those pages in front of the client so they can visually see what's going on. That helped quite a bit. So
Isaac: Awesome.
Jeffrey Sherman: Awesome. well we are running long and I don't wanna cut everyone off, but I have to cut everyone off. so Ravi,
Isaac: Yeah.
Jeffrey Sherman: if people wanna find out more about you, where can they find you?
Ravi Ram: Yeah, my website's Dully.com. That's spelled D-H A-L-I.com. and you can find us there. I'm on LinkedIn, Robbie Ram Dully. Just add my company name. There's millions of Robbie Rams out there. So just make sure you add my company name to it and I'll pull up there. And yeah, I love the chat. Matter of fact, the way we're meeting today is I listened to one of Mark who was on your podcast. He was local. We had a cup of coffee and he says, Hey, you gotta, you know, try to get on the show, and that's why we're here. I love that. I learned so much from just the face-to-face. sitting with you guys here talking as well is nice. So yep, that's best way to reach me as well.
Jeffrey Sherman: Awesome. Thank you so much, Ravi. and thank you all for listening. I'm Jeffrey Sherman.
Isaac: I'm Isaac Askew, and this is Never Rewrite.