013 RR Technical Debt

Download MP3
  • Deliberate technical debt - deferring development to when you can later afford the time
  • Inadvertent technical debt - adding technical debt without realizing it or because libraries/frameworks go out of date.
  • When would you deliberately accrue technical debt?
    • Time crunches
    • Everything pretty much devolves down to time
    • Deferring for lack of expertise
  • Shorten time to market by trading time.
  • Lean Startup
  • What’s the right solution? Fix your code? or rewrite your code?
  • Quantify the cost of your technical debt - Josh gave an example.
  • Sources of Technical Debt:
    • Upgrade costs
    • Test coverage
    • Application features
    • Non-core features
    • Compatibility costs
    • Coupled code
    • Dependencies
    • Early adoption
  • Solutions:
    • Versioning
    • Upgrading
    • Do the work
    • Bypassing the problem - Solving it a different way
  • How do you know you’re adding technical debt?
    • When you start to feel the pain.
    • When you make the initial payment.
  • Technical debt is a deficiency in your code or process. It’s costing you time.
  • Counter-examples:
    • Code you don’t need to maintain
    • Code you can avoid without incurring immediate or eventual cost
  • How do you avoid technical debt?
    • Good abstractions
    • Good refactoring
    • Refactoring (by Martin Fowler)
  • Declaring Bankruptcy - Folding up the project? Restarting/rewriting?


CHUCK: Hey everybody, and welcome back to the Ruby Rogues podcast. This time the recorder is running, and so we'll go ahead and get started and welcome our panel. On our panel today, we have Aaron Patterson. Aaron is on the Ruby Core team, or at least has commit rights to Ruby and Rails as well. He works for AT&T Interactive, and he blogs at tenderlovemaking.com. Welcome, Aaron. AARON: Thank you. CHUCK: We also have James Edward Gray. He is the author of the Textmate book, he ran Ruby Quiz for a while, wrote the FasterCSV library, and has contributed in a lot of other ways to the the Ruby community. Welcome. JAMES: Thanks. I'm glad to be back again. CHUCK: [Chuckles] And we also have Josh Susser. Josh is… [chuckles] I drew blank again and I closed my notes. He's one of the organizers of GoGaRuCo, that's right. I got it. [Chuckles] JOSH: [Chuckles] CHUCK: He's made some contributions to Rails and blogs at blogs.hasmanythrough.com. That’s why I write these things down, sorry. JOSH: Right. And so it's not weird for people, I actually do have a job, but it's like a little startup thing, so it's to early to talk about it right now. Someday though. Anyway, hello from sunny San Francisco! CHUCK: Yeah, the early start up stuff is kind of fun, so maybe we'll have to talk about that one, one of these times. I'm Charles Max Wood. I am the host of the Rails Coach podcast, the Teach Me To Code podcast and screencast, and I am a freelance Ruby in Rails developer at Intentional Excellence Productions. And you can find all my stuff at teachmetocode.com. JAMES: So can I share an embarrassing guffaw with the audience now? CHUCK: Yeah, go ahead. JAMES: Okay, so we just did ten minutes plus of a Ruby Rogues episodes without having the recorder on, so this is like time traveling for the rest of us. We have all lived this moment already, we've gone back in the Delorean, Aaron is going to tell the same bad jokes -- believe me, we are suffering, okay? It's just what I wanted everybody to know. AARON: Yeah, but the jokes will be twice as funny this time, right? JAMES: I'm sure that’s what it is, yeah. CHUCK: Because we've heard them twice, right? AARON: Exactly, yes. [Chuckles] CHUCK: All right, so go ahead. Let’s get into this. JAMES: Okay, so should we give a brief recap of where we were? JOSH: Yeah, sure. So we started with the definition, and then rapidly went to field. But I´ll try my definition again, and I´ll say that technical debt, if you wanna take on debt deliberately, like you are going out for a loan in the finance world, it's deferring development until a point when you can better afford the time to do it. Maybe you  don’t want to write as many test upfront as you think you should, or maybe you wanna use some quick hack that will solve 80% of your problems, and then you defer the rest of it until later when you can better afford the time to do it right. CHUCK: Right. AARON: I have a question for you Josh, how do you distinguish occurring technical debt from just doing agile development? Because when you are doing agile development, you just wanna do basically the least amount of work possible and get the result you want, right? Would you say that? JOSH: I think that’s part of Agile development that… AARON: You see where I'm going with this? Like, where do you draw the line between doing the least amount possible and it just turning into technical debt? How do you make that decision? JAMES: So my opinion on that is that maybe you don’t know you're occurring technical debt at the time. Like for example… JOSH: Oh, no. there's definitely cases where you do know it. JAMES: Yeah, I agree, but that mean like when you get like 3 upgrades behind and stuff like that, I don’t know that you’ve intentionally made the call. Like, “Oh, we're just going to eat this technical debt right now,” or something. JOSH: Right. And that’s not the deliberate technical debt or the intentional; that’s the inadvertent. And there's definitely cases where that happens and that's either you weren’t paying attention, or you are…  I'm not sure what. [Chuckles] But in terms of Aaron’s question, I think that there are definitely times when you want to slack a little on writing the best code write. Say you have, “Okay, we really got to get this product release out because time to market is important. So let’s just skimp on our tests or not write our acceptance tests or maybe we'll just use an old package of an old library that we know isn’t going to work on all the browsers we want, but it will work on most of the ones that we want.” So you essentially, a half ass job because there's more considerations… there’s considerations that are more important than getting it done right. And then you can come back later when you can afford the time and fix it. CHUCK: So are there any tradeoffs that are worth it other than other time tradeoffs? Because that’s what we are talking about ultimately, is we don't have time now, so we're going to take the time later. Are there any other reasons for accruing a technical debt other than time constraints? JOSH: I think everything eventually devolves down to time, but in a more proximal thing, maybe it's expertise, maybe you don’t have anyone on your team who knows how to do Flash animations, so you just do something quick and dirty and something else, instead of going through all the process of learning how do to Flash. That does end up becoming a time consideration in the big picture. But in the small picture, it's just because you don’t have the right person on board. CHUCK: Right, and you don’t have anyone with the time to learn how to do it themselves? JOSH: Right. JAMES: Can there be advantages to technical debt, though? Like for example, can we say, “Hey, let’s do this so-so implementation of this feature using this library that we're pretty sure isn’t going to meet all out needs, put it up there, see what the users tell us what they want and then go from that and iterate forward, even though we are nowhere probably building an implementation that we're totally okay with chunking in the future to rewrite the way we really want it.” AARON: The advantages are absolutely, like James said, it’s time to market, right? I mean, that’s what it is, period. You need to get that product out there as quickly as possible. So you are hoping that if you get it out soon enough, you can buy time later using money that you’ve earned, right? JOSH: Yeah. And if you are an adherent to the Lean Startup philosophy, that what startup to do is that they prove out new business models. Startup is a business for converting money into a new business model, I guess that is what they said. But the business of a startup is to figure out what business they are in -- and to prove that. And writing a really airtight code base is not the fastest way to get there. And if you are going to put a lot of effort into writing good test coverage, and making sure that everything is going to be awesome and easily deployable everywhere and that sort of thing, your automation for everything you do, that's a lot of effort to put in to something, that is not proven as a money maker. So if you wanna cut corners on all these details and things that I would consider really important for the longevity of the code base, it's okay to do that. I think it's great to do that if you are consciously making the decision. Just like it's great to go and get a mortgage to buy a house; if you don’t have a million dollars siting around and you wanna buy a house in San Francisco, you got to take a mortgage out. But hopefully you work for a startup, in a couple of years later you have a million dollars to pay it off, right? CHUCK: Well, one thing that comes to mind too with Jame’s question is not just the time constraints or even the Lean Startup where you don’t want to invest a ton of time into something that you don’t know is going to pay off. But even if it does pay off, it may not pay off in the way that you think it ought to, and so by putting something in that works for 75% of your target market, and just kind of make sure that it works well enough, you may find out that you need to pivot it just a little bit, to make up the difference and make things kind of roll in this new direction. And so if you spend a lot of time building in this other features, and tightening down all of the different screws that you need to get that feature in, you may find out later that you didn’t need it. AARON: Yeah, but I think there was a huge difference between going into a project and saying, “All right, we know that we are cutting corners here and probably like we may have to change it, but we are okay throwing stuff away,” or “We know that we are going to have… basically planed technical debt.” I think that there's a huge difference between planned and unplanned technical debt; like if you know that you are getting into that, then you can kind of plan for it in the future. The worse is when you find out you have… you are getting this inadvertent technical debt and you have to deal about it later on down the line -- that is the worst. JOSH: And the worst is when you are assuming someone else’s debts. [Chuckles] AARON: [Chuckles] CHUCK: Yeah, and this is where the government jokes come back in. The ones that we didn’t record, right? JOSH: [Chuckles] JAMES: I couldn’t believe we didn’t get pregnancy jokes off of Aaron’s ‘planned and unplanned.’ [Laughter] JOSH: So James is talking about a project that he is doing now. James, do you wanna talk about the debt issue on that? JAMES: No, I already told that story once, it's lost all the appeal for it. [Laughter] All right, all right. So I'm working on a project right now, where my job this month is to rewrite a 40,00-line Rails app, and it was written for Rails 1.2. And it's been kind of brought forward. It was technically running on 2.2 when I got it, but even there, it's just mostly using 1.2 stuff, and Rails is still accepting it with a lot of deprecated warnings. Then they want me to bring it up to Rails 3, and it was written in a 1.8.6 era and they want it running on 1.9 and stuff. So it's a very large amount of technical debt, but the application is very complicated, and some of the things that it does are very involved. And so it looks like it's going to take me right about a month, as far as how far I am and how far I have to go. So they basically had to pay me for a month to just sit there and go through it, and get the whole thing running on a modern Ruby on Rails -- and that's my job right now. CHUCK: I have to stop you real quick; if James isn't here next week, it's because he either was committed or slit his wrists. JAMES: Right. AARON: [Laughs] JOSH: [Chuckles] So James, I feel for you. I had a very similar experience earlier this year. We had a client come in and they had a 20,000-line Rails application -- with no test coverage whatsoever. JAMES: I should have mentioned this one did sort of have tests -- sort of -- when I ran about half of them failed, and I looked through them and evaluated them and I decided that actually, I didn’t think the test were we're saving, so I threw them out right off the bat. JOSH: How did you replace them? JAMES: So what I did, I did it in a different way this time -- and I guess time will tell if this was smart or stupid. I made a new application, a brand new, untouched application in Rails 3 as the app and what I'm doing is I'm slowly bringing things over. So I'm going through the models. Now keep in mind this probably sounds a bit anal and maybe slow and stuff, but keep in mind we're talking… there's some models in here that are over 1,000 line or some controllers that are the same way. And I wouldn’t say that it's normal for me to get more than 3 or 4 lines before I see something that probably needs cleaning of. So I am literally reading every file line by line as I bring it over, plus I had the advantage of familiarizing me with the code and stuff, so I see the things that it can do. And it has tons of problems like copy and paste programming and things like that, that I have the opportunity to clean up and stuff.  So I'm slowly bringing it over as I go -- bit by bit -- and putting them into new things. So I just recreate the new models and that gives me a better test suite, like Rails always would. And then, as I have time, obviously, I will not launch with anything remotely new good test coverage. But you know, I didn’t have that anyway, so I didn’t really give up anything, you know? AARON: So you had technical debt, not only in your implementation but also your tests? JAMES: Yeah, the tests were pretty much worthless. I would threw them and they just… I didn’t feel like they made me confident about anything in the app, so I just ditched them. AARON: [Laughs] JOSH: So my project sounded similar. We opted to just do a full rewrite. It is 20,000 lines of code. There was a lot of duplication in the code. There was a lot of very poor code in the application, and it looked like for the functionality that was going on, it was like 3,000 to 5,000 lines of code, maybe. And so I talked to the client and convinced them that that was the best way to fix the application. Because it would have taken them months to go back and put in decent test coverage in these things and refactor and upgrade it to Rails 3. So we started over and we we're informed a lot by the old code. It was a lot of work, but 6 or 7 weeks later, we had about 3,000 lines of code that implemented about 80 or 85% of the functionality of the old application -- and everybody was happy. CHUCK: Yeah, we went through something similar at one of my past jobs. And I was the project lead pretty much right after we went over the cliff, so I just kept us from falling in the wrong direction. And after not too long, we wound up going to the CEO and saying, “Scrap this and rewrite it.” And it turned out to be a really, really good thing -- both from the perspective of, “Yeah, we have a whole lot cleaner code, lot better test coverage,” and things like that, but we also then understood the problem domain. And that was the problem initially was that we would built something, it would not be right because we didn’t understand the problem domain. And so effectively what we would wind up doing is we’d wind up re-hashing the code over and over again, and we wound up with all of these extra garbage in there that would break stuff when we got to where we needed to be. So the rewrite there, it did… it’s not a complete lost when you have to do a rewrite because you wind up with the domain knowledge of nothing else. AARON: I don’t think rewriting is. I mean, I'm not sure why we make such a big deal out of it because you have to do… you have some technical debt that you have to deal with, right? And… JOSH: And you make a balloon payment. CHUCK: [Laughs] AARON: [Chuckles] Exactly, yeah. You have to make a decision though as to whether or not you… you have to go in and take a look at it and figure out how much time will it take you to either fix the current code base or just completely rewrite it. But it doesn’t matter because in the end, you theoretically are ending up with the same functionality -- either direction you take -- you just have to choose one that has the least amount of time. So I mean, I don’t really know why it matters so much. JOSH: Or you can just raise the debt ceiling. AARON: Exactly. Yes, thank you! But I hear that takes an act of congress. CHUCK: [Chuckles] One that we might not get. JAMES: These are the same jokes. [Chuckles] AARON: No, I´ll tell you exactly what you do. You issue one trillion dollar coins, I was reading an article on CNN today, we can issue trillion dollar coins. CHUCK: [Chuckles] I was listening to… JAMES: That’s awesome. CHUCK: …I think it was the Planet Money podcast, it was either that or This American Life, and they were talking about all of the dollar coins that they have sitting in a vault somewhere, that none of the banks don’t want because their customers don’t want them; they just want the bills. So they have the coins, they are sitting around somewhere. AARON: Is it possible for us to issue more debt on a project? Can we do that? JAMES: [Chuckles] Issue more debt on a project? AARON: No, I mean. Can you keep pushing forward? Like let’s say you are on a project, and you know you have a lot of technical debt on it, how do you push forward and continue the debt? I'm just curious if we kept this going. CHUCK: You just keep writing code. JOSH: Well, to continue with the painful metaphor, who is your creditor? AARON: I guess your business people? JAMES: Yeah, the company that hired you, I guess. JOSH: Yeah, so paying off debt, servicing your debt, I think is a good think to talk about. I had a project earlier this year, where it was built on an old version of Data Mapper. It started off as a Merb application on Data Mapper -- which was pretty hot a couple of years ago -- so it was about a two year old code base. And we kept talking about the Data Mapper text, because I and my pair partner would work on this together and in a given week, we figured we spent 20% to 25% of our time just dealing with Data Mapper issues. Because I don’t know if you are familiar with the issues of Data Mapper, but there was a fairly significant rewrite between 0.9 and 1.0 -- which made it really difficult. It basically dropped a lot of technical debt on people who were using 0.9. So suddenly, I guess that was like the Data Mapper imprinting new money. [Chuckles] AARON: [Laughs] JOSH: It suddenly meant that anyone who is on 0.9 had a huge amount of work they had to do to upgrade it to 1.0, so a lot of people just chose not to do it and started a crew and interest on their debt at that point. So when we stepped in a year or two later and started working on this application, there was a huge amount of debt around. And that meant that pretty much anything that we had to do to touch the database took us 20% or 25% longer than we felt it should have. So on a given week, we would spend upwards of an entire day just dealing with the weirdness of Data Mapper and how broken it was in the old version, and its inability to do things the way we thought it should work. So that tax was very real, and when talked to the product manager about it, and we were able to quantify that and say, “The last three weeks, we've spent upwards of a day a week just dealing with weird Data Mapper issues,” that gave him the numbers that he could use to figure how much money he should put in to paying people to migrate them from Data Mapper to Active Record.  So that’s a very financially savvy way to take a look at dealing with your technical debt. JAMES: You know, something interesting, I guess sometimes it's hard to see as it's coming up for how expensive it really is. Like for example, as guy who spends all day everyday right now converting from Rails 1.2 to Rails 3.0, I didn’t feel like at the time, that the rails upgrades where particularly painful to me that was. But having done it now for a while, I'm shocked at coming from 1.2 to 3.0, exactly how much I'm having to do – it's a lot. I mean, the queries changed from, it used to be find everything, then it was first and all, but they still had basically the same parameters as the finders did. And then it was Rails 3’s syntax with the methods and stuff. I mean, tons of little things that ERB changes, that with the way it forms are interpolated into documents and things like that. I think these guys had a knack for using Active record methods that never caught on; like they like to do instead of ‘model.find’, they like to do model with brackets and I guess Active Record used to support that way back when, and you can just put the ID in the brackets. And it was a kind of like you were indexing a hash but, apparently it doesn’t support that anymore, so I'm changing all those defines and things like that. But I'm surprised and taken aback by how much work it is just to move from Rails 1.2 to Rails 3. It's a non-trivial thing. And if you throw Ruby 1.9 on top of it too, it's an even bigger scenario. CHUCK: So I wanna jump in here, and we've kind of talked about quantifying the cost, and James and Josh, both were talking about upgrade costs. But, what other types of technical debt are there? You know, other than just upgrade costs, what else do we see? When we said that we can see them in the tests. Are there any other examples that you guys have? AARON: I can think of one as application features; stuff that you provide to end users that may not necessarily be core to your business. So I think like business people can accrue debt, but I don’t know that that’s technical debt necessarily. JAMES: For sure, doesn’t Rails have the same problem? I mean, at times, Rails has provided features, that then later they decided were a bad idea to put into the core of Rails because they were beholden to those users using those features, and that really didn’t made sense for them and they yanked them out or whatever. So sure, I think that exists in software too, doesn’t it? AARON: Yeah. JOSH: I think compatibility. AARON: Oh, yeah. JOSH: As new platforms come out, and you don’t jump on these platforms, maybe add some depth for you or maybe you choose not to try and support the platforms, but then one of them becomes popular. CHUCK: Right. AARON: Yeah, I mean fortunately with software development, we can at least use version numbers and stuff to our advantage, right? So we have a system for getting rid of this debt or for phasing it out at a time and getting rid of it. But when you have like an application that you are providing to the end users, I mean, it's difficult to set these deadlines with other people. It's not as hard and fast as the version schemes we have. I guess that’s a double edge sword through, really because you  could take away features anytime you want. [Chuckles] CHUCK: Right. So one other technical debt that we ran into in a couple of the jobs that we worked on is just coupled code where you have… I mean, it got to the point where you would touch one piece of code and something would fail in something else that is seemingly unrelated. And the reason was is because it touched this portion of code, which touched this other portion of code, which touched this other portion of code, which touched the portion of code that you changed, and it messed something up on the other side of the app. JAMES: Chuck, show us on the doll where the app touched you. [Laughter] CHUCK: Oh, man. This episode is not going to go well for me, is it? [Laughter] JAMES: So library dependencies are I think a big source of technical debt. You are dependent on a library. And this was a big problem with like the Ruby 1.9 adoption or upgrading to Rails 3, where you're using gems or plugins that were critical to your application, but they haven’t been upgraded to work with Ruby 1.9 or with Rails 3, in one case or the other. And so you are stuck until you either help upgrade those dependencies and get them running in Ruby 1.9 or figure out some other way to implement the feature without using that. JAMES: So yeah, I think that's an excellent point that I'm very curious about, because that has been the biggest thing in this application for me, I mean I would say, I know there is one model that had nine plugin dependencies -- and I've seen that a lot. I would say if I had to animal up this thing, probably was dependent on about 30 libraries. And obviously they were all what's hot in Ruby 1.8.6, and like you said, around the 1.9 era, we basically picked new horses because we had to rewrite them all in the same way. So most of them are gone. So I'm wondering, at what point was that technical debt incurred? Was it incurred when they decided to use the library, or was it incurred when that library quit being maintained? CHUCK: Hmm. I have an interesting thought in the same vein, and that is that this app I'm assuming, if you had a server out there that have Ruby 1.8 and Rails 1.2 on it, would run fine forever, right? So I mean… JAMES: No. I mean, I guess I see what you are saying; what if that app had been perfectly stable and was running. And I swear I have seen apps like that before, where it's running fine on the old stuff and they don’t really need to upgrade. But that wasn’t the case for this business. Their problem is, this was kind of side project for them, that they had to held on to for a couple of years and had never really decided if it was going to become big for them, and now they have decided it is going to become big for them. So this basically started by them coming to me and saying, “We need to add this, this and this.” And I looked at them and said, “Well, I can do that, but it's very old and I can't use a lot of modern tools on it that would make it easier for me to do that. So it's time to decide if this is a long term project, then maybe it's realistic to bring it up to current standards.” CHUCK: Right, so I guess what I'm submitting is that in either case, whether it was running fine before or not, maybe their technical debt was incurred when they determined that they needed to upgrade because again, they weren’t losing anything by not upgrading, in the sense that they didn’t have an already working, running app out there that they needed to upgrade. JAMES: Yeah, that's true and I guess that kind of goes back to what you said earlier, Chuck of like maybe you don’t always know… I mean, obviously you don’t always know when you are incurring technical debt like your other example that was very good, was about coupling. Coupling tends to happen over a period of time without… I mean, obviously if we knew that we were putting a dangerous dependency in there, we would probably choose another way if it was equally easy. And if it tends to pile on and pile on until you realize that, “Oh, for some reason, when I touch this one, this thing over here falls down and dies.” And I don’t think you intend to get there, but it happens overtime. AARON: So one thing that worries me is, like how do you tell when you started adding those types of things to your code base? I mean, I can tell these sort of stuff, but I don’t think there's necessarily any books that told me how to do it. It is just out of experience; like while we don’t wanna do this, or this or you know, how do we educate people  to know that… how do you see these problems? JAMES: I think there's an early adaptor payment that you always incur. We're talking about dependencies and the debt that you can accrue by being dependent on a library or a gem that doesn’t get upgraded to run on Ruby 1.9, for instance. So when you start using that thing, you have to evaluate the benefit that that gem is going to provide you. Oh, somebody else wrote this code, I can use it really quickly. I don’t have to spend weeks writing that for myself. But that's a great thing, but you also have to weigh that against how reliable is the resource of this gem, and are they going to support it over time? So there were a really cool flash in the pan plugins that came out for Rails that are not supported anymore. And like James, if you were working on a project that was dependent on a bunch of these plugins, what do you do? [Chuckles] JAMES: Mostly, in most cases I've written them just that… I guess you'd kind of be surprised, like at one point, it was using feed tools and feed tools doesn’t work on 1.9. And I pulled it down and fiddled with it to see how tough it was going to be to get it running on 1.9. I took a first pass at it in like an hour and ran it. It was still having problems that I couldn’t totally see, so I decided this was a dead end. I didn’t wanna be stuck with all that debt. So I went back and try to figure out what the code was really using feed tools for . Ad I find out that, “Eh, actually it’s pretty trivial thing.” I loaded the Ruby standard RSS library, I wrote about 8 lines of code and it was problem solved. It was not a difficult need. So there probably ought to be a lesson to it is using a plugin that does all these things is great if you need that, but if you don’t need that -- if you can get away with the 8 lines of code -- maybe you should try that first, because you might incur less technical debt long term. CHUCK: Yeah, one thing that I wanna point out -- directly answering Aaron's question -- is how do you recognize you're adding technical debt, I think the thing that comes to mind for me, because I couldn’t think of any specific instances where you are saying, “If you are doing this, or if you are seeing this and that means you are adding this type of technical debt, more it seems that when you start to feel the pain.” When you are starting to pay the cost initially, that’s when you start to recognize, “I have this technical debt.” So for example if every time I do a git pull, and I'm getting my test aren’t passing anymore, that’s telling me, “You have some technical debt here.” And the technical debt is in my process, not in my code. And the technical debt is, “I need to see a machine that tells the other developers on my team, ‘Idiot, run your test and make sure they pass before you commit.’” Or you know, there are a lot of other things like that, but you don’t recognize those things as things you are going to have to pay off, until you make that initial payment. I was working over in this section of code, and this other section of code fell apart. That’s your first indication that there's some correlation in the code that you didn’t see in your mind. So then, you start looking for the technical debt and find a way to either decouple them or to define their relationship between them. JAMES: And I don’t know about you guys, but like when I'm running into those scenarios like Chuck is talking to, I always feel like the little orphan that has to go back to business and ask for another ball because, “Oh, we have this problem now and sorry to bring this to you, but we are going to have to fix this,” you know? CHUCK: Well, I think there's something to be said about that too, because if you have good business people -- because usually it's the business people that are going to say, “Oh you wanna push the timeline or you are going to need more money,” or whatever -- and in those cases, if you have good people understand the process, then you should be able to explain to them, “This is an unforeseen thing. It will solve this problem in this way,” and they are usually good with that. If they are not, that’s when you run into problem. And I don’t know of a terrific way of solving that. You were going to say something, Josh? JAMES: Yeah, I was going to say what… I think it's worth for us taking a minute to talk about what is not technical debt. Because I've heard us talking about things that are maybe technical debt and maybe not, and it depends on your perspective. And I think that some people talk about technical debt as just being bad code or crappy engineering or something like that. And I think there's a distinction to be made. You know, from my perspective, technical debt is a deficiency in your software -- or maybe your process -- there's something some technical aspect that you want to be better, but it's not -- and it's a deficiency. AARON: It's something that's making you take more time than should have for that particular thing you need to do. JAMES: Right. But there are things like in the financial world,  there are things that you just make a payment and you are done with it. And there are other things that you have to keep paying off overtime. And that’s the thing that I think of as technical debt; it's the things that come back to haunt you overtime. AARON: Your interest on a loan. JAMES: [Chuckles] Yes. CHUCK: [Chuckles] Yeah. So what are the other counter examples then to technical debt, Josh? JAMES: Well… JAMES: So Josh you are saying that you don’t think just playing bad code is technical debt, is that what you are saying? JAMES: Well yeah, I mean if there's something that is essentially all rolled off, like if you are using a gem or something. And internally, it may have a lot of technical debt, and be hard to advance the gem or develop it or fix bugs or what have you, but that’s internal to that gem; it's not in your project. And it's not something that you have to worry about. Up to a point. But it's not something that you are going to be making payments on. It's not making your life more difficult being a client of that gem. JAMES: As long as they don’t ask you to add a new features to it that’s really difficult to do it. JAMES: Yeah, I mean you are crossing a line at that point though. And it can even happen in your own codebase. I've worked on code bases where there were parts of the code base that you didn’t wanna touch it. And I think you could look at that as technical debt, but you just keep avoiding it, and it doesn't really impact your velocity, it doesn’t affect your ability to add new features. It is just some isolated subsystem of the application. So you just ignore it and it's not really debt. AARON: I think what you are trying  to say is that if you have good abstractions in your code base, then you can sort of relegate off this little… ‘keep the cancer from growing’, right? JAMES: Yeah, I'm glad you said that because I wanted to bring that. One of the ways of preventing things from turning into technical debt… and i think those abstractions are important. AARON: Yeah, good refactoring and good abstraction… you know separating your code into good abstractions is probably the best way to do it. I mean, it can still leak in to your system. Like if you ever need to do something a little bit different with that gem or with that API, then you are kind of screwed. But you know, at least you have good abstractions there, so you can define that where your code meets that other code, you can define it well. That is the way to prevent it from spreading. JAMES: So Aaron, you talked earlier about are there books that teaches how to avoid these kind of things and stuff like that. And my knee jerk reaction when you said that was, Refactoring would be a book that I would name. And then you just mentioned it again right there. I think maybe that is in a way that refactorings are based around removing couplings and things like that -- building better abstractions for the stake of welling off pieces of code. AARON: Right. So the problems with that is like you are dealing with the problem afterwards, right? I'm talking about say, how do you convince other people that good abstractions are good things, right? Like we can say that to each other and it's really easy because we know, “Ah, down the line we are going to have to be paying a cost for this,” and we know that pain is. Like, how do you teach someone that pain without them actually going through it? CHUCK: Well, I don’t know that you can. I mean, that’s one of things… there are a lot of this that I've gone through with junior developers, where I’d explain to them, “This is the way you wanna do it. This is why you wanna do it.” And ultimately, they do it that way, but then a  few years down the line, they come back and they say, “You remember when you told me to do this this way? Well, I did this other one this other way,” and oh my gosh, I just haven’t seen any substitute for it. I mean, some people will take your word for it, but most people, it doesn’t become second nature until they have suffered through it at least once. JOSH: [Chuckles] I agree. JAMES: Yeah, I think that's even more realistic. And there may even be scenarios where you know, I mean if I'm doing quick and dirty scripting, then I'm not usually caring about the level of abstraction. And for me to sit down and write probably doesn’t buy me anything for a script I'm going to run a couple of times and then throw away. But I was going to ask, maybe there's a different way to… Aaron, can you name any technical debt that’s currently in Rails? AARON: [Laughs] Probably? JAMES: Migrations? AARON: Yeah, migrations. There you go. That’s a good one. JAMES: So how did that get there? Was that a conscious choice? I mean, it was a conscious choice to add the feature obviously, but I don’t think they realized at the time what they were doing or what they were incurring, maybe. JAMES: And I think you are right about that. Can people still hear me or am I gone? CHUCK: Yeah. JAMES: Everything got really quiet, so I think everyone just muted at the same time. [Chuckles] CHUCK: Yeah, that happened to me a few times. JAMES: [Chuckles] Okay, so I think  you are right James, that migrations, people in good faith said, “Okay we are going to build this feature, and we're going to build it the best way we know how.” But unfortunately, there were some I think better way of doing, that if they have done things in a little more object oriented way or used some of the more standard patterns, if they had had things be … instance methods instead of class methods, then it would make testing easier, it would make the implementation of the code easier, dealing with engines would have been easier --  all that stuff. And I've hit my head for any weeks against the migration code in there, so I know a lot of these issues that’s why I brought it up. But it's like Chuck was saying that it comes with experience. So just like an inexperienced financial person might end up buying a bridge in Brooklyn, because they are naïve about that, I think that developers going through this experience don’t notice that they are writing codes that might cause trouble in the future. CHUCK: Well, I think we all have different experience, and so some of the things that would be second nature to James or Aaron or you Josh, to me I just go full speed ahead, and I wander off the cliff because I didn’t know it was there because I hadn’t made that mistake yet. And I'm sure there are other things that you guys do, that the other of you knows better. And yeah, it all comes down to what you have been through, and what your experiences and what you’ve seen and learn from there. JAMES: Right. As you gain enough experience, then you are driving over the cliff on purpose. CHUCK: [Chuckles] As long as you have airbags. All right, well I think this is a good time to end it and go into the picks. I explain this every week, I'm going to explain it again. Basically the picks are just things that we've picked up, learned or experienced that we liked, that's made our life easier. And so, they can be code related or non-code related. I'm going to go ahead and let Aaron start us off this week. AARON: Yeah, I think this one will be good for our topic. Probably a book that if you haven’t read this book, you need to buy it now; Working Effectively with Legacy Code by Michael Feathers. This will help you get out of technical debt. And it's awesome; it changed my life with regard to software engineering so get it. CHUCK: All right. Is that everything? AARON: Yes. CHUCK: Okay. James? JAMES: So I'm not recommending useful programming stuff this time, but I've become obsessed with three letters by some strange condition. So the letters are S, G and U. and it turns out that in January, I found this podcast that I got hooked on, and it's called Skeptic’s Guide to the Universe Podcast. And it took me like 6 months to catch up on it. It is usually shortened to ‘SGU’. And it's a podcast for skeptics, so If you like hearing about cool science studies about things like UFOs or Acupuncture or thing like that, what's true that we believe is true, what's really does science to back it up, things like that. It's really a cool podcast. Lot of fun, great, great casts that does it. And actually, one of the ideas I had for running this podcast is based on that one is their paneled discussion of the topic. And so that’s one. And I got obsessed with that and went all the way through it. And then I got done with that recently. And my new thing I've been hooked on is Star Gate Universe. I’ve been streaming that on Netflix, which is usually shortened to ‘SGU’, so for some strange reason, anything SGU, I seem to really liked. But Star Gate Universe is a Sci-Fi series. And it's very good, these people for way the far end of the galaxy… you know the story. They are way out there and trying to get home and stuff. But really good character development and great show. So I'm recommending Skeptic’s Guide to the Universe and Star Gate Universe and anything else that’s abbreviated as SGU. CHUCK: All right, Josh go ahead. JAMES: Okay. I have one pick this week. And for most people listening, who are not lucky enough to be at GitHub’s code Conf in April, it was a really great conference. I had a really great time there. My favorite talk of the conference was Coda Hale. He did a talk called Metrics, Metrics Everywhere. And it was such an awesome talk, that I got him to come to Pivotal Labs while he's still there and he gave one of the lunch time tech talks and it got recorded on video, so that video is now up on the  web at pivotallabs.com/talks. And it's the kind of talk that I think every software developer really needs to watch. It's about how to create business value, how to create code that has value as opposed to debt, and how to make decisions about your code based on actual data, rather than guesses. So it’s a great talk, and I encourage everybody to spend a few minutes watching it. I think it's about 46 minutes and it's worth every second. CHUCK: Awesome. Thanks. My pick this week is an app for the Mac called Wunderlist. And it's a to-do list app. and you can share your to-do list and things like that. And I found it extremely useful for me to just kind of keep track of all the stuff that I have going on, and I've also created a list for my virtual assistant. And so then I can see when things get done, so I can see when my podcast episodes get posted or when somebody that she need to email got emailed or things like that, because she marks them off the list and I can go and see what she says she's done and I can check up on the ones that are critical to me. Anyway, that’s something that I've been using recently. Anyway, that’s pretty much all I have. So we'll cue the music, and just thank you guys for coming again. This week we had on our panel, once again just to remind you who they are, we had Aaron Patterson, he is a Rails committer and Core committer, and he blogs at tenderlovemaking.com. Thanks for coming, Aaron. We also had on our panel, James Edward Gray. He is the author of the Textmate book, Ruby Quiz and the Best of Ruby Quiz, and the FasterCSV library, so thanks for coming, James. JAMES: You are welcome. CHUCK: And Josh Susser, one of the organizers of the Golden Gate Ruby Conference, GoGaRuCo. He's on twitter @joshsusser, he's also contributed to Rails and he blogs at blog.hasmanythrough.com. Thanks for coming, Josh. JAMES: No problem. Great to be here. CHUCK: And I'm Charles Max Wood from teachmetocode.com. And we'll catch you all in another week. You can get the show notes at rubyrogues.com. Leave us a review on iTunes. We really, really appreciate that. AARON: Thanks, guys. CHUCK: All right.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.