The Stack Overflow Podcast

How long does good code last?

Episode Summary

This week we chat about the half-life of the software you create. Why does some get refactored after six weeks while another program goes untouched for years? How do you know when it's time to say goodbye to your codebase and try a new architecture?

Episode Notes

This week's discussion was inspired by an article from Sandi Metz, which you can find here. It begins with a terrific line, defining the half-life of software as, "the amount of time required for half of an application's code to change so much that it becomes unrecognizable."

This topic also connected to a post we ran on the Stack Overflow blog this week,  Sacrificial Architecture: learning from abandoned systems. The author, Mohamad Aladdin, suggest that one should "think of your code quality as if it will run forever, but adapt to change as if your code will be obsolete tomorrow."

Our lifeboat badge winner for this episode is Ishmael, who explained why JSON dumps your formatting and how to fix it.

Episode Transcription

Sara Chips When I think of SQL Server, I do a moment of silence for all those DevDiv meeting rooms in Microsoft with people yelling at each other.

Paul Ford Can you imagine what that was like? Just--

[INTRO MUSIC]

Ben Popper JetBrains Space, a unified platform for the entire software development pipeline and team collaboration. Combine Git hosting, code reviews, CI/CD packages, planning tools, issues, documents, chats, and blogs, all in one place. Bring your software teams together to communicate and deliver high quality code faster. Get started for free at JetBrains.space. 

BP Hello, everybody! Welcome to the Stack Overflow Podcast, a place to discuss all things software, programming, code and technology. I'm Ben Popper, Director of Content here at Stack Overflow with my wonderful co hosts, Paul and Sara. Hello!

PF Hey! Alright. We got some technology out there, is there some technology going on?

BP I think so. Yeah, all kinds of tech going on! I have two stories that I share with y'all today to discuss or possibly to discuss. The first is called the Half Life of Code. Just about like, if you work on something, how long should you expect it, you know, to be valuable and worthwhile to you before you might have to replace it, deprecate it, update it. And the second one was a piece published on the Stack Overflow Blog called Sacrificial architecture: Learning from abandoned systems, which is about how and when to make the decision to sort of, you know, completely refactor, or you know, redo your architecture. 

PF Alright, so that first that first question, the question is, what's the half life of your code, right? Like, how long is it going to last and be functional? The answer to that is really wild. Because sometimes in the there's one example given in the piece, where it's like six weeks, you just refactored everything, everything. But then there's also those moments where you pick up something you worked on, like 14 years ago, or the GitHub repo from early GitHub days where you're like, where somebody's like, "Hey, I picked this up and started using it." And you're like, "No, no, no, no, no, don't go in there." Right. Like a horror movie. What about you Sara, where have you ever dealt with your own ghost code?

SC Oh, yeah. Oh, yeah. And it's really shameful. And you don't remember. Like, I don't know her? I would I don't I don't remember her. I don't know the person that wrote this thing.

PF No, yeah. Who was that? You know what else I will say very often you go back, sometimes you go back and you're like, a garbage monster was here, otherwise there's no explanation. But other times you go back and you're like, this is perfectly fine. If you'd asked me what kind of programmer I was, I would have said, I'm a terrible one. And I should never have been allowed to write code ever. But then you read it. And you're like, it's okay. Like it could be better. 

SC Yeah, that rarely happens, I feel like. And that's nice. That's the nice time that that happens.

PF Well see you're taking it like 'that's nice.' I'm like, 'Oh, God, I've learned nothing in 12 years.' [Sara & Paul laugh]

SC That's fair. 

PF You're actually not as bad a programmer as you think you are. I think that is true. Right?

SC Yeah, that's the number one thing we should tell new programmers. That's like the number one. You're not as bad as you think you are. I think that's always true.

PF Simultaneously, you're much much worse.

SC Much worse, yeah. [Sara laughs]

PF It's really tricky.

SC Yeah, so one thing that he talks about is the half life of code and re writing code in a way that it's easily replaceable, as a way to optimize for that. And so a lot of what I did after reading this article was starting to think about what that looks like.

PF Well, these are the two great, the two great dreams of everyone in technology are reusable code and good documentation. Right? And reusable code like that gets all the way up to full on object oriented, you know, don't repeat yourself.

SC Modular, yeah.

PF Everything's modular, here's a class library. And you should only have to kind of glue things together. And then there's the kind of like, well, everything is clearly documented. There's the famous Donald Knuth line, sort of that code is, is really kind of communication between people that's only supposed to be incidentally, operated by a computer. And so the reality is that, you know, we I think we can just be frank about this, we're on Stack Overflow Podcast, like, reality is a lot harder to modularize when you're doing your job every day. You're gonna cut and paste a lot. I don't think we should penalize people for that. I do think--and also, when does the boss ever say, hold on, the smart thing to do is to take a month modularize organize our thinking and build a library so that we can build on top of what we're doing. The people who do that, like work at Microsoft.

SC Yeah, no, I think that yeah, I think that's true. I think it's really easy to write modular, reusable and replaceable code when you're writing greenfield, right. It's like, you know, I'm thinking from the beginning, but when you're in, you're writing a feature, you're in the middle of someone's class that was created 10 years ago. There's function on top of function in there, you need to shoehorn your feature in while changing a bunch of other things. You only have a week to do do it. I think it gets a lot harder.

PF That's the thing, object oriented code, right? And sort of modular code often makes more sense. When you truly are modeling out a thing that is a little less abstract, like, oh, shoes, well, shoes have laces, you know, or like, you know, things that you can look at and be like, 'Okay, well, we're gonna, we're gonna add methods here that you know, let you add, you can add ears to your dog' or whatever the hell it is. And then there's a whole part of modular code where it's like, connect to API, single thing class, unless failure [Sara laughs] is the name of where you're actually dealing with the things that the computer is all about. And that is always to me when you read that stuff, you're like, Oh, this is where you need geniuses, because we're now talking about abstractions that have like a world that I can internalize and understand, like 'A hand has fingers, oh, cars have wheels! Wee!' But you know, you also have a Byzantine General synchronising problem when you're talking to the you know, and the ROM needs to take that into account. And you're like, 'Not wee!'

SC Yeah, and sometimes those geniuses need to say, like, I've seen it happen so many times, where it's like, I've got this beautiful class, it's really, you know, a lot of single responsibility principle, it's super module, it's, it's, it's really beautiful. And then you have this weird edge case, and you got to shove a function in somewhere, it's either gonna be here, or in the factory object or somewhere. And sometimes the geniuses are like, you know, what, it's just gonna be ugly. We just got to do it. It's either that or rewrite the whole thing.

PF It's adult decision time, right. And that part sucks. Because everything beautiful, just at that moment, you just see all the beauty slipping away, you know, and especially like, it's culture, right? Like, I find Python, very, very easy. Even abstract, weird Python, data science, Python, I find it really easy to read. I'm good at reading Python. I'm less good at reading JavaScript.

SC I actually was just thinking yesterday, the reverse, I am the reverse, we make a great team.

PF No, that's right. Actually, as much as people say, the Python is more readable. I don't I think if you're in the culture, and you know, the conventions of the language, that's the one that is the most readable, Python looks a little more structured with the with the whitespace indenting. But ultimately, that's actually a lesser consideration. You know, typographic formatting actually becomes like a lesser consideration. When you know how to read. Like, for me, when I was getting into closure and learning lisp, like learning how important it was to kind of both be reading left to right and right to left, like seeing the, you know, that the alligator was eating the different S-expressions and kind of swallowing them up and then you know, that it would give me some output, took me a long time to just get it. That's not taught necessarily, you don't get taught how to read code, you get taught how to write it.

SC Yeah, I was talking, I think reading code is a really important skill. I was just, someone was telling me about a company that does their engineering interviews by reading code together, instead of writing code together, asking people to, you know, do bubblesort or--

PF That's so real, that's a great idea. Because you're just like, "Hey, what do you think about this?" Right? You know, and then actually, what's interesting there is the person who is is looking at it going like, "Wow, I never thought about that way. But that is a great way to solve it." That's a very powerful signal, because boy is it nice when you read code, and you're like, "Ohh!"

SC Because that's your main job, isn't it? Like, when you're a programmer, you're just like, especially when you're on a big team, is reading code.

PF Yeah, I mean, what is it--you know, people are like, wow, you're gonna implement algorithms, like you implement an algorithm, you use three letters, PIP, or NPM. [Sara laughs] Those are the three letters that we use to implement algorithms. That's my programming language. NPM, whatever it's called.

SC NPM Install bubblesort.

PF Yeah, bubblesort, all your different sorts. And, you know, and also, I mean, we don't really externalizes this. We talk about, you know, cloud services and so on. And certainly, databases are just lovely collections of algorithms that operate over sources of data, right? Like, they're just great. And they make it really easy. And then they give you interfaces, like indexes. We keep thinking of databases as programming, but they're really just interfaces to algorithms that that allow for efficient retrieval and search of data.

SC And thank goodness for those saints that wrote them.

PF Oh, my God, I sometimes I just--I have a little candle, a little candle with the Postgres picture, every now and then I light it. SQL lite is a different one, just like I give a little, I just touch my heart every time I say it. Yeah. Oh, you know what, unsolicited plug. Steven Sinofsky, who was very critical to Windows development, especially in the period where it went from Vista to like Seven and Microsoft was saved.

SC An important one, yeah, yeah. 

PF Yeah. He's got a substack. And it's really good. It's about early days of Microsoft. Hardcoresoftware.learnbyshipping.com, right. And it is just, I don't think it's for everybody. But if you're the sort of person who's like, 'Oh, really, they were trying to build a kind of shared interoperability object layer...' and like you actually see, all the same ideas that we're dealing with now just get working out like, like, essentially, at one point, he was in charge of something that was a lot like react, but inside of, you know, as opposed to instead of dealing across browsers with a component model, it was supposed to work inside of both Windows and OS 2, and you can see the ideas taking shape. And then at any given point, Bill Gates could show up and blow up your world. So you're just yeah, it's the big boss, right? 

SC It's always the fear. 

BP If he works out the history over like the course of a year of substacks, then he'll have to turn it into a book. This sounds like that.

PF It definitely feels like he's he's writing a book live. It's pretty cool. So anyway, I would just like--it's a deep nerd cut, but this audience is the one that will most align. It's pretty good. When it comes into my inbox--I won't say this about many substacks--I'm just like, Oh, yeah, hey, wow. 'Cause instead of somebody being like, "I'm gonna tell you why the economy should be reorganized along monarchical lines." It's somebody going like, "Alright, I was just out of college and I had to think about object oriented technology." You're like, I could empathize with that.

SC That makes sense. I just signed up.

PF Good. Good. I haven't paid yet, you have to pay to come in. But you know, blurbing it, so really aren't I giving it attention as a form of payment? 

BP You're getting all your thoughts here without paying, nice. Free rider. I like it. In the sacrificial architecture post, something came up from Jeff Atwood, who's connected to Stack Overflow deeply as a co founder, performance is a feature, which I thought was interesting. And they were saying that a lot of times when you're creating something new, a new project, a new feature, what you want is adoption. And so you want to make sure you have this like sort of product market fit. And so performance isn't the most important thing. He was using eBay as an example, which is originally written in Perl, Paul, which the Swiss Army Knife of coding languages.

PF Oh everybody calls it that. Don't criticize Perl.  

BP If you have the good problem of Oh, suddenly have tons and tons of users that you have to think about maybe refactoring or rewriting or changing what you're working with. Because now, you know, a few seconds here, there might make a difference against a really big competitor. Do you have any experience with this?

PF I don't know if anybody else does this, Sara, maybe you do. But when you log into a website, and you get your password wrong, which happens to me, because now 90% of my time is spent logging into websites. That's how you use the web today. And you get your password wrong. It clearly has to do a little database check. And but it usually comes back like super fast "Oh, no password. You got it wrong, do you want to reset?" But when you log in, and you get it right, it actually chews for a minute. And then you get to your account, and it loads the whole app. And so that to me is like this moment of profound failure where like, oh, yeah, the failure states really easy, because you're just like, didn't match. The match state is like, oh, now we have to load this, we have to load the whole app. And it's like, what have you been doing? You had my whole computer the whole time? Why am I waiting two seconds for a spinner so that you can give me a kanab view? 

SC Yeah, didn't you already give me 100 cookies? You can't see that it's me?

PF I always say, in my head, is just my little name for it is the bite, like the moment where it bites down. I don't know why I always think of it that way. But that to me is like that's the pure moment where they didn't optimize because it's my first, I'm walking back in and instead of go like, "Oh, hey, Mr. Ford. Good to see you. We got that, we got you know, here's your coffee." They go. "Oh, God, you're here!"

SC "Oh, my goodness. We haven't been expecting this."

PF "I have to hit like five API's? What do you use? Is it decaf? Oh, boy."

SC "I have to put a sweater on"

PF Yeah, exactly. Right. And this, I think speed is really hard. It's really, really hard. It's probably the hardest thing. Because everything that you want to build to make everybody happy is the opposite of speed.

SC Yes, anything new, anything nice.

PF Anything your boss asked for. Anything in process. is going to be suitable. Or like the business logic or, you know, we need to hit--what about the analytics, right? I mean, there was a long period of time on the web where every ad call was blocking. And it still some of them still are. And that meant that the page would stop loading so that you could get the ads and that was that moment, in the like, mid to late 2000s, where the web just kind of died. Like you just couldn't look at anything. 

BP I definitely have had that experience. And now right, it's given me this like backwards relationship where when I enter a login and I click in it sort of hangs for a second then I'm like, "Oh, good. I got it right." The waiting is now the good feeling of like, Oh, I know I didn't mess up my password or my Password Plus Google Authenticator plus fingerprint ID, etc, etc, etc.

PF Oh, the worst is when they give you, its acts like a kanban, like you move from one board to the other. It's all in theory supposed to be instantaneous. And yet, touch got--mobile did make people do--like mobile performance speed is really important. Like if you have a slow app, it's bad and it's perceived as bad and people complain about it and give you low ratings. But like once you get into the enterprise state, like, there are older versions of Salesforce, they're speeding it up. They called it Lightning, which sounds fast. But like, you know, you click a drop down, and then you could go get a cup of coffee, read a book.

SC Yeah, one thing I'm obsessed with on mobile, and you can really tell when people are thoughtful about this. And this is like slowly happening. Is component, individual component loading. This is like a very react thing. I'm sure other I'm sure other people are implementing it as well.

PF Is that where you do the tree shaking?

SC Yes.

PF Yeah. There you go. Now you got your, okay, so tree shaking, component loading, sorry, cut you off.

SC So when you when you see that, like you're able to see some of your data, some of your data is coming soon. That makes me feel good. That makes me feel like the developers are thinking about my experience.

PF The nice thing about the tree shaking and some of the JavaScript calculation environments is that with gentle hinting, the computer will do the work for you and figure out what needs to be loaded when, that is optimal, it is really hard to get this right by hand, it's almost impossible, right? Because there's so many little moving pieces. And the way that modern web apps work is you have 1000s of components. Some of them are your components, and some of them are other people's components. And it's just really complicated. So when the computer is like, here are the paths that seem to be most likely, we can make the JavaScript smaller to load, that'll make the browser a little bit faster. Here we go. And then there's, you know, there's server side rendering versus local rendering, and all these things you can do. Now I've just added, if I have a year long project, I just added two months to it.

SC Yeah, yeah, it's a tough one to prioritize.

PF The customers are out in the field. So making speed part of it from day one is really important. But you're also there, that's a trade off. That's absolutely a trade off.

BP One of the things that really frustrates me is that my MacBook has a fingerprint sensor. And yet, you're never allowed to use that almost when logging in on the web. That's like one of the joys of mobile apps is like, just take my thumb and I'm, ouff, love it. I don't understand--

SC Or your face. Mine takes my face.

PF The absolute tragedy of Google Pixel 3 to 4, because I dropped my Pixel 3, probably the favorite phone I ever owned.Because it had this little thing on the back, it put this fingerprint sensor on the back. So you would just like pick it up. Your finger actually had a place to rest to kind of hold the phone. And then that was your login.

SC How have we made it this long without realizing that y'all are androids?

PF Oh...Sara...yes of course.

SC Wow!

BP I have an iPhone.

SC Oh okay.

PF I like to switch ecosystems whenever I break the phone.

SC Well that's weird.

PF It's good. It's healthy. It's healthy.

PF It's not that I really care too much. I want all of the giant mega corporations to have control over my life and data.

SC You're supposed to pick an allegiance, Paul.

PF No, no, I want to please them all so when it comes time and they really do run the world, they don't judge me. You know, there'll be a point where Tim Cook stands and says, "Let's look at how you lived your life" and I don't want to--

BP Then you hold up your Pixel 3, and he knows what side you're on.

PF It's gonna be weird when you go to heaven and it's either him or I don't know. I don't know who--

SC Satya. 

PF Satya. [Paul laughs]

BP Using your mobile device at the pearly gates. This is dark. This is dark.

PF When they look at your search history. That is, oh, it's grim. Nobody's even done that cartoon yet. Where like St. Peter just brings up your search history and is like "You're not coming in here, what are you talking about?"

SC If that's the criteria, I am set, I am set. I got this Google Doc spam the other day, which is new, but it was threatening me and saying that it knows my deepest, darkest secrets, and the disgusting things in my search history. And I was like, this person hates yoga pants. [Paul laughs]

PF "I know how many times you visited Crowd Supply" "Why are you shopping for Raspberry Pis? You have a perfectly good supercomputer?" "Oh, no, please don't tell my wife!"

[MUSIC]

BP Alright, everybody. It is that time of the show. I am going to read you a lifeboat badge winner, somebody who answered a question with a score of negative three or less. And their answer got up to a score of 20 or more, rescuing some knowledge from the dustbin of obscurity. Today's lifeboat badge award winner is Ishamael. Thank you Ishamael. Awarded two days ago for answering the question: "json dumps format Python, I'm reading a JSON file" adding a field and then writing to a new one a new JSON file. The problem is, as you can see, this isn't a visually readable as the original file. I can read it line by line by line but it's printed as one single line in Sublime Text. How do I keep that formatting? Well, there is a parameter. I won't spoil it for you. So check out the show notes, but there is a parameter to help you my friend. Thank you everybody for tuning in. We really appreciate it. If you liked the show, please leave us a review and a rating, it really helps, or email us podcast@stackoverflow.com. I'm Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. 

SC And yeah, and I'm Sara Chipps, Director of Community here at Stack Overflow. And you can find me on GitHub @SaraJo.

PF And I'm Paul Ford, friend of Stack Overflow, check out my company Postlight and we are hiring, design, engineering and product management. Please, please take a look. Love everybody! Bye!

[OUTRO MUSIC]