Two's Complement - Avoiding Abandonware

Episode Date: June 17, 2024

Matt and Ben explore the unfortunate death and rebirth pattern of software systems. Ben botches a quote from Bjarne Stroustrup, and then explains why you can't go back in time and kill Hitler. Matt exhibits all the bad things when describing a serialization library.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey Ben. Hey Matt. So this is the first time we've recorded this while we listen to our own jingle to start with. Yeah that's right. And I can't help but grin. It's so weird. It's so weird. I was expected to I'm so used to listening to this while I'm editing it. Uh-huh. And then I had to remember oh no I

have to speak now. Yep. So what are we talking about today? I had a vague idea of something that we can talk about and as usual i have 12 pages of copious notes on this topic so there's no risk that i'm going to run out of things to say in fairness i don't think there's a risk that i'm going to run out of things to say on any topic at any time true but uh i have done zero preparation for this. So there's a chance that this is our first. We'll see how it goes. That'd be fine. But the idea that I had is avoiding abandonware. Oh. I think that we can talk about a particular phenomena that occurs a lot,

that I see a lot in the software industry, that I read about a lot that I see a lot in the software industry that I read about a lot in software and technology and finance, basically any company that uses software, I see this phenomena. And it's regrettable and somewhat avoidable, but also like many things is a product of sort of systemic forces. And it may not be possible for you as an individual to avoid it. Right. But it is certainly possible for companies to avoid it. So I think we could maybe...

That's interesting. I mean, it immediately makes me think of that XKCD with the big pyramid of things that companies have built upon, you know, from the bottom up, all these different pieces. And then there's this one thing like at the bottom right-hand corner, a tiny little sliver of a stick arrow is, you know, that one library that some guy in the middle of nowhere is the only person that's supporting. And it's like, well, you're talking about one step beyond that where nobody is supporting that thing anymore. Well, yeah, that is a particular, so that it's like the load bearing internet person.

Yes. Who's like, you know, like all of modern technology is propped up by this one guy in Sweden, right? Right. So this is not like, I think some of the same forces are at play here. But what I'm talking about is, is within the context of a company, um, a situation that I think occurs a lot where people will build a piece of software and it will go through certain phases. And the phases are roughly like in the early days, there's a lot of excitement about it. There's a lot of change that's happening. There's a lot of new development. And then the software starts to stabilize,

and then the software starts to kind of freeze, like be stable in a bad way. Like ossify, really. Yes, ossify. That's a great way to describe that um and then because it is difficult to change the organization will start routing around it because they need change to happen because the world is change but they can't change the software for various reasons which we'll talk about and then other bad things happen when they start routing around it. So I kind of want to walk through that sort of whole process from beginning of end to end of like a typical project, right? And how it and how it suffers this fate. And what happens to the people involved in it? And what

happens to the company? Right? I'm intrigued. Go ahead. So so starting off, I think a lot of projects, you know, the sort of Greenfield project, right? And'm intrigued. Go ahead. So starting off, I think a lot of projects, you know, the sort of greenfield project, right? And many of us have had opportunities to work on greenfield projects and they're great. And the reason that they're great

is because they have zero complexity, right? And there is no dependence, no customers, no nagging you about it, no bugs. You have no bugs. You have no dependencies.

You have no code that you need to read. You have no slow test suite that you need to run for 12 hours before you can do a deployment. Right? You have nothing. And it's great. And not surprisingly, one of the reasons that programmers love those kinds of projects is because they are very productive at the start. Right?

And I think part of the reason why is, or they can be. You can also get tied down in a lot of like, you know, analysis paralysis and other things. Yeah, what technology should we use? And like, well, yeah. Yes, yes. So that can certainly happen and does. But there are many situations

in which you started in one of these projects and you have a very clear idea of what you want to build, or at least you have a rough idea, right? Like maybe recalling our iterative versus incremental episode, which, you know, maybe you're like, well, I'm going to paint the Mona Lisa. So I know roughly what she looks like, and I'm going to pencil that in. And that's going to be my first draft, right? And you have a very clear vision in your head and you can be very productive. And as a person who likes writing code, there is maybe nothing more fun in the world than having that vision in your head and making it real, right? Or making some draft of it real, right? And so you're very productive. And then, you know, eventually if you're doing your job well,

you build some software that somebody wants. And like the Bjorn Stroustrup quote about, there are two things in the world, the polling languages that people use and complain about and the ones that they don't use, right? And I'm botching that quote terribly, but I'm hopefully getting the idea right. The precise wording is much more- Pithy.

He's very good at that. But it's this where you build something that somebody wants and they immediately start complaining about it. And they're like, oh, this is great, but can you add this? And can you do this? And can you change this? And can you do this? Often with the word just in it. Right.

Can you just make it 10 times faster? And so what happens is that you start having to adapt to change, which you didn't really have to do at the beginning. At the beginning, you're in this phase where you're like, I have this vision. I'm going to build a thing. I'm going to build it until somebody says, ooh, that's cool. And they start using it. And then you start getting some feedback. And some people will tell you to try to get to that phase as soon as possible.

That's maybe a whole other discussion. But eventually at some point in the process, you're going to start, if you're successful in building software that someone wants, they're going to ask you to change it, right? And they're either going to ask you to change it because the world changes, or they're going to ask you to change it because of some new capability that they want, or they're going to ask you to change it because they encountered a bug. But whatever the reason, they're going to ask you to change it. And then you're going to be in this process of changing it, right? And you're going to change it and change it and change it and change it. Now, I think we've kind of talked about before we were in our technical debt episode

about complexity and how complexity is one of those things that I think is a more useful thing for programmers to talk about rather than the metaphor of technical debt. Especially given how folks reasonably disagree on what debt is. Ward's original idea is not how I use it and so on and so forth. So complexity is something that I think we all have a better understanding about what we mean when we say this is complex and there's necessary complexity and then there's the other kinds right right yes and i mean very very uh uh practically here it's like you start out in the greenfield project you have zero lines of code right you get to the point where you've deployed your first version and someone uses it and you have n lines of code and then you get to the point where you're making change number 5,263 and you have some multiplier on end lines of code. And that is complexity,

right? Whether it's more complexity than you need or less, it doesn't really matter. It's complex and it's hard to change and it's hard to understand. And it's hard to add more people to the team so that you can add more changes, right? And all of this gets slower and more difficult and harder. And eventually you reach a point where the people who are asking you for changes start to get frustrated because the changes aren't coming quickly enough. And in dysfunctional organizations, this can lead to situations where people are pressured to work long hours to try to get changes in. And then, you know, usually that adds to more complexity because they're a bleary eyed in the middle of the night trying to figure

out how to do things. And that just makes the problem worse. And then it just gets slower and slower and slower. And eventually that frustration reaches a point where people say, okay, we shouldn't count on this system being able to change quickly, right? That's not a good strategic plan because they have shown in the past that they can't change quickly. And, you know, there are some really negative things that happen when a project reaches that stage. You know, people start seeing that the future of this thing isn't really going anywhere. They start to leave, which means, you know, you have a loss of talent working on the project, which again, makes the rate of change even slower. And you lose the institutional knowledge that they had when they leave.

So yeah. Exactly right. Exactly right. So all that complexity that was maybe loaded up into someone's head, that head is now somewhere else right now, and you can't use it to figure out what the hell's going on in this code. The organizational support might start to get pulled away, you know, in terms of funding or in terms of, you know, other resources that the organization can provide, you know, it starts to be thought of as this thing that is, that is, uh, in a more positive light, maybe stable and, and

useful, but in a negative light, something that is old and crusty and legacy and no one wants to deal with. Right? Yeah, yeah. But the needs of the organization are still there. And the reason that you built the software is probably still there. And so what happens is people start to route around it. And initially, they may start to route around it by doing things on their own that the system also does or also could do. But for the reasons previously stated that it's difficult to change, they choose not to or they feel like they can't. And that can be real or imagined. It doesn't even really matter. Right? And so you almost get this like scar tissue where it's like the organization starts to like,

like work around this thing that is part of the organization itself, like this critical piece of software, but they start routing around it. Right. And what I see quite often, and I think that's a pretty common pattern. And what I see quite often is that it can easily reach sort of a tipping point where people start to say, like, maybe you have like an inflection point almost where it's like two core developers leave the team or they leave the company because they're sick of working on this legacy thing that no one cares about anymore. Right. And then maybe they hire a couple of new people to come in and take it over. And the new people look at it for two months and they're like,

oh my God, this thing is so complex. What we need is a rewrite. Right. And now, the cycle begins anew. You have a greenfield project where you get to do the whole thing over again. I mean, there's well-documented version two problems. Yes. Second system effect and all of this other stuff, right? And, you know, in dysfunctional organizations, this prog, this process of, you know, renewal and renewal is a way too positive of a term.

Phoenix from the ashes kind of thing. It's not nearly that good for anyone. Yeah. Um, just happens over and over and over again. And so, you know, um, I, I think, you know, there are some ways that you can accidentally encourage this and there are some ways that you can help prevent it. Uh, I think that at some point it is almost like the natural outcome of every project to sort of reach this point where it becomes difficult to change. And that can be for a number of reasons. It can be because of the complexity. It can be because so many people depend on the existing behavior that there just isn't that much left to change. Right.

Right. Right. The thing that immediately springs to mind when you talk about this is a lib curl and the curl command line, right. Which is used in every program ever. And I know Daniel, I think his name is i i've subscribed to the his uh github repo and i can see the changes going through it's like or zlib is another one you know um that's another one i i find it fascinating to look at these

things which are essentially immutable and can't change ever again because you know like gzip files have to keep working deflate as a spec and it isn't changing uh but they are maintained uh but and you'll see taking a zedlib for it as an example you'll see like lots of people come in and say hey i'd love to make this thing go faster i want to change this thing whatever and they're immediately closed down with like yeah but unfortunately that exposes this issue and this bug you're the 15th person to try and make this change it doesn't work really sorry gonna have to write an faq for like why you can't do this or something rather than this and it's well meaning but it's like it can't

change because it is like so fundamental to everything uh yeah you know that's that and likewise curl i mean obviously both of these projects still go curl is probably more actively maintaining as things are being added to it and whatnot. But like it is, it's a core piece of infrastructure in the world. And necessarily it has to be conservative in its change now, even if change is required. Right, right, right. And the people who are there in the more functional forms of this, the people who are there, the custodians of these stabilized projects have probably seen it all at this point, right? Like if you come along with some bright idea, like it it's probably it's probably in the issue list like it's not new it reminds me of this sort of satirical thing that i saw once of like the uh you know back this is this is going

to date me a whole bunch here like the the forum like the bulletin board for the time travelers association and this the sticky post at the top of the forum is uh do not go back in time and kill hitler because if you do then no world war ii which means no darpa which means no internet which means no time machine which means i have to go fix this again so do not go kill hit. That's the sticky post. Right. And it's sort of like the obvious thing is like, Oh, can't you just,

can't you just do this? And in those mature projects, it's like, don't you think that we would have by now, if we, the poor gray beard driven over their beard as they are. Yeah. It's like,

well, let me tell you a story. We tried that in 1977 and it didn't work out then yeah many people have tried since you know we've talked about this with comments actually in our comment episode right there was the comment where it's like you know you put the explanatory comment that says please don't change the following line it looks like it should be changed to this but whatever however if you want to try it and get it working and get all the units passing then go ahead but if you don't come back to this comment and get it working and get all the unit test passing, then go ahead.

But if you don't, come back to this comment and bump the number. And the number is like 27. 27 other people have failed, weren't you? Yep. Yep. So I think that's like the functional version. Because like I said, I think every piece of software will undergo this life cycle. There's like the Greenfield sort of explosion of activity.

There's, you know, you can do anything you like. You can completely change the API once a day, once an hour, even because you've got no users, even once you've got one or two users and they're happy enough, you can sort of say, really, sorry, we're just completely revamping everything. You're going to have to migrate and we'll either help you or good luck, you know, move over to it. And then you reach the sort of middle age part right so that's sort of like your youth and then your teenage years when you've got you can be a bit spiky still because you know your users are kind of like well okay i guess so and then you become a middle-aged person or an adult and now you're like well i can't just go and change this thing because you know thousands of people

will be affected by this and so you have to slow down and be a bit more sensible and boring and then you know but then so what be a bit more sensible and boring um and then you know but then so what's the midlife crisis version of this what is it changes anyway it goes haha we're rewriting all in rust i mean i think i think this is like i think this is the you know do you have are you like a you know cheeseburgers six times a week uh no exercise sedentary you have a heart attack in your 50s project oh i'm gonna go somewhere else with this oh no yeah right um or are you the like you know super exercise uh multivitamin you know the whole thing and you live into your 90s right

and the way to like achieve that sort of like longer life cycle is to preserve your ability to change for the things that are really important. Right. And not sort of fall into the trap of, oh, we're trying to cram everything in here, but we can't. So what this needs is a rewrite that can do all the things. And so there's lots of factors to this. One factor is being able to like manage change over time for a very long period and being able to say no to changes that don't make sense, as we sort of have been talking about here. Another thing I think is understanding that projects should only ever really get so big, right? right if you try to cram everything into your system you're going to either have to throw a ton of resources at it to be able to manage that kind of change and it's still the cost of that change is still going to be incredibly high but a better way is okay maybe we don't have to rewrite

this what if we just made something else that could fulfill the needs right which like or split it in half right that's another way to do it. There's a sort of version two-ish feeling to that, because that's one of the ways of avoiding the trouble and the problems of changing an existing project for which you have downstream customers is to essentially make a new version and say, well, never the twain shall meet. This is a new API. It's a new version. You never need to touch it. It's essentially a new version and say, well, never the twain shall meet. You know, this is a new API. It's a new version. You never need to touch it. It's essentially a new project.

And that is a way of managing the change aspect of it. And what you're saying is you could split a project in two. I guess it's a different dimension there. What you're saying with one is you're saying, like, this serves the need of something. And you're saying that the only reason you would rewrite it, well, no, not the only reason. A reason to rewrite it is because the internals are so hard hard you can't change it you can't make those changes and i'm thinking well there's also there's the periphery there's the

the external interface and it's very hard or maybe even impossible to have a good experience when you have to support like a v1 api and a v2 api yes it be done. And obviously you can think about it beforehand, but yeah. Right. Yeah. And like the V1, V2 API, I would be less suggestive of that. And this is more about like,

as you're getting those requests for like, can it also do this? And can it also do that? Really thinking about like, should it do this? And should it do that? Like, I'm not saying that your request isn't valid and that we shouldn't build that capability within our organization, but I'm just saying like, maybe add in this code base, right? Because if you look for those opportunities, then you're reducing the complexity of the system

and also creating opportunities to deliver on those requests quickly because you're potentially doing it in something else. If you're just throwing it into your code base because that's where your build system is and you've got the deployment already set up and not because it actually belongs there, that's going to hasten your demise as a software project, right? That's like eating the cheeseburgers, right? It's not good for you. So that is sort of like one way in which I think you can kind of deal with this, right? ossified is to say well okay let's let's not put lots of things into it which brings us possibly arguably unnecessary complexity right then also tangles our feet that makes it harder to change down the line and then eventually we kind of abandon the project to move on to v2 of the thing or something different entirely yeah yeah that i could understand yeah yeah and that is separate from like splitting it so like one one approach for this is if you've identified parts

of your system that have stopped needing to change right like like you're not getting any like like you're you know message bus dealie whatever it is i don't know whatever whatever part of the system it's like yeah we've got this code it's in the code base we run the tests on every build we haven't changed it in three years right maybe that's a library and it's gonna be a library you don't share with anybody just pull it out compile it one time run the test the one time and if you ever need to change it it's there but you don't have to carry the complexity costs of that forever right and that's sort of a cheap way to split things we've talked about things like uh

the the anti-pattern of commenting out code because it might be useful before now and this seems like a sort of similar feel to it where you're saying look uh it's not that i want to delete this code it's valuable um i'm just going to extract it and put it somewhere else and it's slightly more live than in source control and gone in my current incarnation because it's been published as a library separately. I like that. I like that.

The usual argument against it, which is the one we did with the whole commented out code or code that you don't use that's in your project, but is that refactoring tools and things like that can bring it along for the ride. But if you can find a nice seam to extract that library that's less of a problem anyway it's like yeah well this is where the compression library goes we're not using compression anymore but it's a really nice component i'll take it out we'll put it in the in the the company drawer of like useful little

components and then uh we'll get on with our life i don't have to keep it up to date or i don't have to do anything with it but it's there if i need it. Well, and I'm saying like, even if it is being used, even if it is actively being used, but it's not being changed, right? Like you go through and you look at your Git history and you see like, yeah, we, this code is executed every day in our system. We haven't changed it since 2014. Right. Fascinating. Yeah. Yeah yeah i actually have a perfect example of that in my current code base where we lazily so this is exhibiting all of the bad things actually so it was a serialization library and uh in order to have like this the the tools that um like command line tools that allow you to decode and re-encode and dump and debug serialized forms

of data there's a number of applications that go alongside the library that you would otherwise link with and as i was writing that out i it was one of the first times in the company that we had a bunch of native code and so i wrote a somewhat straightforward and small application like cli app framework with command line parsing and all that good stuff. And so convenient that in my subsequent projects, although I started off needing the serialization library part, I'd actually pull across the application framework as well through the library.

I'd be like, oh, this is cool. We'll use it in the rest of my project. And now, of course, the serialization library has gone by the wayside, but I'm still depending on it because it's got this application framework. And I'm like, this is terrible. I'm pulling this huge amount of complexity of the serialization library to get like 15 lines of code that now if I needed to change, I have to cut a new version of the serialization library. And that is a smell and I should go and fix that sooner rather than later in myself. But yeah, it's easy to happen. I see what you mean.

Yeah. Yeah. And with all of these things, your ability to do this is going to be a function of your ability to decompose and refactor, which unfortunately is changing the system. So if you wait until the system is hard to change before you start thinking about these things, then you will never come back. Right. And you will,

and you will wind up in that place where you are like, you know, the, the bad Phoenix where you're, you're, you're trying to rewrite the whole thing. There's a username, bad Phoenix. Bad Phoenix has entered the chat room. So, so I, I. So I think, again, I keep drawing parallels to health and the sort of middle age and everything. Is that top of mind for some reason?

Yeah, right. Well, there you go. Maybe the tacos and beer that I had last night has this on my mind. Is if you want longevity in these projects, if you don't want them to ossify and then be completely routed around and then rewritten, then you have to have a long-term view on these things. You have to be like, I realize that we don't need to break this out now, but if we don't

start doing things like this, it will be very difficult to do later. And then we just practically won't do it. And that means that we won't be able to change it. And then the organization will route around us, right? The problem is a lot of organizations, and this gets into some of the structural causes of this phenomena. A lot of organizations take a sort of project oriented approach to building these kinds of systems. Yep. Right. They don't think of them as, uh, you know, the people and the software. Like when I think of software, it's like, I think those two things are, are inseparable.

Right. Like, uh, you know, handing someone a code base with no team to go with it is like a curse, right? It's like, if you want to slow someone down, like, you know, take like a, like an unspecified chunk of code and be like, here's this chunk of code from your most successful competitor, boop. You'll like, you know,

kill their performance over the next six months as they try to poke through it and figure out what the hell's going on, right? And so I view that those things as, as inseparable, right? Like if you have the people and you have the code and the code is loaded up into the people's heads and the people know how to change it. And as soon as you pull those things apart and the people move on to something else, the code will solidify. It will ossify. right? And nothing will accelerate that more than pulling people off of the team without giving them the ability to sort of organically replace the folks on the team. It's not that people should stay on projects forever. It's that you should bring people on,

bring them up to speed, and then have other people move off, right? Have a good transfer of knowledge, not like the fake two weeks where you're like, oh yeah, read the code and ask me if you have any questions, right? Like that's not, that's not ready for anyone, right? It has to be like months. But if you, if you have an organization that is project oriented, if you see software systems as you assemble a group of people, they do a project. When the project is over, they move on to the next project. Then you are encouraging this behavior of not looking out for the long-term. And I'm saying, why would we extract the library? I'm going to be working on something else in two years. My goal right now, as told to me by my boss, is add these new

pieces of capability. And I'm not going to stop to think if it's appropriate for this project. That would be not in my best benefit, right? That would not be in my self-interest. If my boss or some of their stakeholders says, add this capability to my project, even if I know that it's not appropriate for the project, it's probably better for my bank account if I add it. Right. Because that's what success looks like at this company, right? Is adding capabilities to software, right? So if that's the way that you think about it, then the problem is, is that this becomes a very sustaining and self-fulfilling prophecy where it's like project number three is rewriting project

number two and project number two is rewriting project number one, right? And that just repeats over and over and over with a new crop of software engineers every few years and a new group of product owners and managers every few years. And they're just rewriting the same, solving the same problems over and over and over again. Yeah. And all of them getting promoted up and out as a result, right? Yeah, yeah, yeah. And I think in very large organizations, especially, this can go on and it's just a huge waste.

And it's like, you know, you wonder why these giant tech companies get so stagnant. I think this can be one of the reasons why it happens is because they have this sort of project oriented view. Yeah, that's a fascinating observation. So what have we got so far? I'm just looking at my list of how to, how to, how to not make abandoned where we actually didn't really sort of define as abandoned where I don't know, but like, you know,

projects that have reached their, their sort of like terminal. Yeah. They've, they've ossified and they've lost their support is how I would describe this as abandoned as in there are no longer engaged, competent software engineers who are working on it. However, slowly in the later phases, right? But working to change it.

Like they have it all. They have all the complexity loaded up into their heads. They can be the ones to answer like, oh, yeah, no, you can't do that to Zlib. And here's why. Yeah. Right. That's the healthy outcome. Healthy long term outcome.

The abandonware is anyone who would work on this project is a sucker, right? No one understands how it works. No one wants to change it. There's no organizational benefit or value or recognition from changing it. It's just sort of seen like this old legacy thing. That's abandoned. And I think avoiding that is important. Right. And so, yes,

to the point one is one way to avoid getting yourself into that situation is to be very careful about what you put into the project in the first place so that you don't add complexity. That's unnecessary, which might be beguiling in the short term. Because if your users need it, maybe you should supply it. But then you end up growing the Homer car, right? If you're not careful.

And then you're like, oh, this is too complicated to even work. And then the project comes to a natural end. What else have we said? Splitting. Splitting. So yes. Splitting software. And you can split it into multiple systems.

You can pull libraries out. You can just change the way your build works. So you can just sort of shove a piece of code over in a corner and be like, yeah, we haven't changed this in 10 years and we're probably never going to. There's lots of ways to split things, but splitting. But splitting and then not paying the cost of having it there. Right. Absolutely minimizing it. So scaling down to zero the cost of hot carrying

a bit of code be it because it's put in a repo and then you don't look at it again but it's there you're shrinking your complexity burden yeah back down again yeah which makes it easier to change yeah yeah and then obviously using techniques that make it easier to change right stop and be you know so obviously the the word that you haven't said so far what word could that be i'm just trying to remember what word uh this thing is it arresting no testing it's not coming to mind all right okay yeah but yes if you've written it so that it's tested and testable right and you've got good tests that help you and don't aren't brittle and don't make it so that you have to do things in a particular way else you know it's hard to change all the things we've talked about once or twice

on this podcast then then it makes it easier to change you know good tests make it easier to make change and be confident that you've made um made the right changes and you haven't broken anything so all those good things that obviously helps the project it's longevity uh i mean maybe implied in what you've said is organizational foresight and usage of appropriate usage of conway's law in the right way to say you know you mentioned project-based development and like moving on from a project to the next project only to have the last one cave in and then you kind of replace it as a sort of almost like a cycle which right certain again conway's law i'm going to bring out here you know you can see that happening maybe with with a consultant-based development where you bring in a bunch of consultants and they yeah

build a thing and build a thing and build a thing and they're like okay we've done the thing and they walk away from it and then a couple of years or maybe less later the folks who are left with the thing are like this doesn't we don't know how to change it. We don't know really what it is. And we hire some more consultants who say, well, it'll cost us this much to take your existing one, or we can write a new one for you. And you're like, well, let's do with a new one. That seems, yeah. And then you, yeah. I mean, I've never been a consultant, but you're nodding at me. No, I have worked on projects that were very much that were almost literally that. Right. Yeah.

I yeah. Sidebar 2009. I did a project for Bank of America, which had recently acquired Countrywide Mortgage in the mortgage collapse. And they had to revamp their mortgage default system because it had gone from processing like one thing a day to hundreds of things a day and couldn't keep up that's actually the human cost set yeah the other side of that it's kind of poignant actually it's it was uh it was a crazy time wow crazy crazy time for me the world um but yeah that was very much that project is that like the right thing to do in theory on paper would have been to take that existing system and scale it up or change it in some way. But it wasn't changeable for various reasons. Right.

And so what they had to do was rewrite it from scratch. Right. Right. I mean, I don't think it's never a good idea to rewrite something from scratch, because sometimes there are some fundamental things that you wanted to change, or you want to try a different way. But yeah, it shouldn't be your default strategy for dealing with a changing environment around you. Right. Right. Yeah. I mean, I think when I think about rewrites, it's like, first of all, be really clear that you really actually do need to do it because it's almost

certainly going to be so much harder than you think it's going to be, but also please make sure this is the last one, right? The cycle ends with me, right? Um right um because and you need to sort of ask some questions like they're you know important organizational questions about like how did we get to the state in the first place like what forces were in play that got us to a point where this code had been abandoned and needs to be rewritten because as an individual person you may not be able to avoid that future unless something has changed in the environment to make it feasible, right? And things do, and it's not to say that you can't, but that would be the first question that I ask with a rewrite, maybe the second question, the first question being like, do we really, really, really need to do this? And the second

one is how are we going to make this the last- last time we do it yeah that's a great thought yeah um so organizational structure yep uh ease of change in the first place yep what am i missing i've already forgotten you see i also went to the pub last night a different pub to you you, but I'm suffering a little bit here. I should have written these things down. Yeah. Splitting the project. Splitting projects. Don't take on functionality capabilities that you can move out to other things that are reasonable to move out to other things. Just because you can add them to your software doesn't mean you should. Think about whether you you can sort of pre split you can think of it as pre splitting right instead of putting it in here and then taking it out again we're just going to put it somewhere else right because it can go there and

it will work fine over there right that's a way to keep your complexity down for me like i actually have pretty specific metrics in my brain for when i start getting worried that a piece of software is reaching its middle age and needs to be, you need to start thinking about how many cheeseburgers a week you're eating. Right. When the lines of code are in the, you know, hundreds of thousands, when the test suite starts to take longer than my attention span, you know, we've talked about the rule of eights before, right. You know, 0.8 seconds. Yeah, that's great.

Eight seconds. Okay, that's fine. 80 seconds. I've lost attention, right? And so when you start making that transition from eight seconds and 20 seconds, you should be thinking, how are we going to split this? How are we going to move parts out of this? How are we going to decommission things?

How are we going to get a little How are we going to move parts out of this? How are we going to decommission things? How are we going to get a little bit more life out of this software? Because if it keeps going like this, eventually it's going to take 20 minutes to run the unit tests and three of them will fail randomly when you do, and you just got to rerun them. And, you know, the build takes a day to actually work and deploy. And any requests that comes in to change the software will take a minimum of a week right yeah yeah yeah so you're you're looking like you've come to the end of your yeah i'm trying to think if there's anything else to say about this and i feel like that's that's probably about it i mean there's other tangents here

that we could maybe go on, but I think the main takeaway is just, you know, if you're a person in a technology organization as a leadership role, and you're looking at your organization and you see this pattern, this dysfunctional pattern of death and rebirth, and you're wondering how to fix it, I think the place to start with is what is your relationship between the software and the people? Because if your model of this is people build things and then they build other things and then they build other things, and you don't have an engineering culture of sort of custodialism, I guess, where you have well-compensated senior engineers who are responsible for software that is a key part of your organization and isn't expected to change all that much because it's in its latter stages of life, then you're just

going to get this constant rebirth, right? And maybe because of your organization, you're just going to get this constant rebirth. Right. And maybe because of your organization, you're incentivized to do that. And that's what you're supposed to be doing there. And that's how you're going to get your exit and move on to your next job. But that's not a place where I want to work. That's not a place where I want to work either. Yeah. No.

Well, I think we've done a pretty good job of covering all the bases. And given this is, you know, as you say, you're 12 pages of notes, which dear listener do not exist. Ben is completely making this up on the cuff yeah uh that was very interesting and i think i'm gonna have to go back and do some refactoring in my my serialization library

which i've been meaning to do but yeah now i feel ashamed you have you have an opportunity to extend your software's life. Right. And you should take advantage of it. I should. Not many people have that opportunity. That's true. Yeah.

All right, my friend. Well, I guess we'll leave it here then. Yeah, sounds good. You've been listening to Two's Compliment, a programming podcast by Ben rady and matt godbold find the show transcript and notes at www.twoscompliment.org contact us on mastodon we are at twos compliment at hackyderm.io at inversephase.com.