The panelists talk to Jared Richardson about Technical and Credit Card Debt.

Transcript

CHUCK: Hey everybody and welcome to episode 46 of the iPhreaks Show. This week on our panel we have Andrew Madsen. ANDREW: Hi, from Salt Lake City. CHUCK: Pete Hodgson. PETE: Hello, from rainy San Francisco. CHUCK: I'm Charles Max Wood from DevChat.tv. I think I'm the only guy on this that doesn’t end in a –son. We also have a special guest this week, and that’s Jared Richardson. JARED: Hi, this is Jared from Research Triangle Park, North Carolina. CHUCK: You wanna just explain to people what you do and who you are? JARED: Sure. I'm an Agile consultant. I do a little bit of coaching, but I also tend to bounce back and forth – I’ll do a year or two of coaching and a year or two of coding. The last run was Ruby on Rails. Done a little bit of writing; my first book, Ship It! with the Pragmatic Programmers is in nine languages, so that went well. Speak in a number of conferences – gosh, I should have done a better job with my [inaudible] description. Mainly I work with teams to find their blind spots. I’ll come in for a given engagement because we need x and then you come in and go, “Yeah, but you're missing y and z” and then we’ll end up focusing on that for the next year. It’s good work if you can get it. CHUCK: Sounds like fun. JARED: It is, it is. I tell people I'm lucky enough to get paid to play. CHUCK: There you go. Alright well, we got you on the podcast this week to talk about technical debt. JARED: Yeah, that’s a talk I've given for a number of years. The title that I usually give it under is a little misleading and I need a better word for it, but I generally call it Credit Card Debt. And people come to the talk thinking that it’s about credit card processing and I lose a third of the audience right off the bat, which was always fun. [Chuckling] One of the things I was taught early in my consulting career is that language is a tool – journalists know it, writers know it – and when we come in and say technical debt, and you try to sell the idea of technical debt to your MBA-trained manager –. To a trained manager, debt’s not bad – there's good debt and there's bad debt, right? Every company out there, if you look at the stock market, they're going to do a debt to income ratio. Debt isn’t an evil word like we intend for it to be. So I tried to step back from that. I'd rather not use a term for something that’s considered bad, when the term isn’t considered bad, so I like to call it credit card debt. Credit card debt is a lot more universally reviled; there's an arbitrary interest rate. If you’ve seen some of the behind-the-scenes stuff, if you have five credit cards and you start falling behind on one, the others will raise their rates, because they know that you're an increased risk. If you start to pay off one, the others will raise their rates because you have money. It’s a dirty, little game; it’s really nasty, and if you're carrying long-term credit card debt, everybody knows it’s bad. A lot of people still do it, right? I think that’s a better analogy. So we talk about technical debt, I will usually refer to it as credit card debt. PETE: I've also heard it referred to – well I guess this is more recent. I was kind of distinguishing between good debt and subprime debt, where good debt is debt you intentionally accrue as part of running your business, kind of that stuff that you were talking about – the debt, [inaudible] ratio. The bad tech debt, the stuff that’s actually tech debt [inaudible] stuff that you accrue without realizing that you're accruing it or realizing it that it’s a bad thing, like a subprime mortgage, I suppose. JARED: Martin Fowler has a pretty good article on that very area of it. He calls it his Technical Debt Quadrant. He’s got the deliberate versus the inadvertent. Again, if we come back to the credit card analogy, if your car breaks down and you have to get it fixed so you can go to work, you put a big repair in your credit card but you pay it off – that’s not necessarily a bad thing. That’s the intentional debt – I'm incurring something for release; I'm ignoring what I know I should be doing, but I intend to pay it off, versus the people that simply live beyond their means. They use the credit card to eat out more often, to go to Starbucks more often, to buy things that they really can’t afford, and those are the development teams who continually ignore what they should be doing, right? If we step back to a technical debt definition, it’s the things you know you should do that you don’t. You feel kinda guilty about it, but you're used to living beyond you're means – you like Starbucks, you like the steak house – so you end up spending more than you have and that credit card sort of supplements the income. And it works fine, until your development or home project reaches a critical mass where you realize you're spending more time patching those little, what were originally small payments, and you're spending more time and money on those than you are adding new features. And then it eventually takes over your budget, and you have the option to pay a lot or declare bankruptcy – neither one of which is much fun. When we talk about technical debt, for those that aren’t familiar with it, some of the examples – and if you guys have any to jump in with as well, that’d be great. I always point to automated bills. Most teams I come into don’t have an automated billed – they think they do, or they used to, until you try to run it, and then it’s not quite there. To expose that, I tend to start with continuous integration. The CI system watches your code; every time you change it, it checks out the code from [inaudible] version, whatever you're using, and runs a build, so that build has to be automated. So your continuous integration system keeps the code clean, keeps it compiling; you don’t have an automated build, you can’t set up the CI system. CHUCK: Now, is there such a thing as good technical debt? I mean, I'm aware that some businesses, at least this is the justification I've heard, when we have to get to market, or we have to get things done quickly, and so we skip writing tests, or we skip doing this or that, and so far it’s working out for us. JARED: Do you intend to pay it back? That’s the question. CHUCK: Some of the businesses don’t really sound like they do. JARED: A lot of them don’t. When my wife and I were younger, I remember one time in particular we wanted some landscaping, and so we put it on a credit card. And then we had a drought and it all died and we felt very stupid later. Did we intend to pay it back? Yes, we do. Did we have any plan to do that? Not really. The problem that companies run into that are always living beyond their means, is it eventually catches up whether we’re talking about automated builds, automated tests, and I'm talking about unit tests and integration tests, but automated in both places; a clean, decoupled architecture, which, by the way, your automated test would help drive. Whether it’s taking the time to do demos for customers; whether you have a developer who’s a knowledge silo because he’s just too busy doggone it, to share with the other developers on the team. So you’ve got this one guy or lady who knows everything about maybe the database layer that nobody else knows, and you're just so busy I don’t have time to pair a program with you. I don’t have time to do a one-on-one peer code review, so rather than get two sets of eyes on the code, we’re incurring additional technical debt. And it feels affordable until that person leaves, or until there's a cool, new project that comes up that that person can’t work on, because they're chained; what they thought was helping the company has now become an anchor, keeping them from doing whatever's next. These things just slowly bill; again, it feels smart at the time, it feels like you're getting more – and you are getting more: you are getting more features; you're getting more Starbucks, you're getting more of what you want, but it’s at the expense of sustainability. PETE: That, to me, is the key thing is that sustainability, that sustainable pace. That’s one of my pet peeves with I think it was [inaudible] that originated the term sprints. It gives the people who don’t understand Agile, particularly managers, start to think that part of the point of the sprint is to try and get stuff done as fast as we can to get down on the end of the sprint when actually we’re in a marathon, right? We’re in a multi-year marathon where a short sprint is actually going to hurt you if what you're aiming for is a sustainable pace in the long term. ANDREW: That’s a good point; comes right back to the language, right? Well let’s make sure we use language that reflects what we really want. JARED: If you were to start off and maybe your goal is to be acquired, and you don’t want to build a sustainable business – and I know people that have that business model – and they're looking to build it and flip it in a year. You might be in a position where it’s okay if you accrue all kind of crazy debt. I'm not a fan of that model. You might be in a position where you're trying to get a release done because you're trying to beat a competitor at the market; you have to be ready for a trade show – for whatever reason, you have to hit June first. If you're going to have a plan for repayment, if you're going to buy the furniture with a “90 days same as cash” deal, and there's a plan in place to have that paid off within 90 days, that's okay. Just don’t make it a habit. Is it deliberate, or habitual? And that’s what you gotta walk, you have to keep an eye on. When you ask about good debt and bad debt, again, Martin Fowler’s Technical Debt Quadrant says, “Is it deliberate, or inadvertent?” If you made a choice, and you have a plan to catch up with it, “We’re going to ship today, deal with consequences next month” – that’s one thing. Versus the inadvertent, the young, ignorant developer – for lack of a better term – just like when I was young and my wife and I were ignorant when it came to budgeting, we just spent more than we had, and it bit us. You'll have the same problem with software. It will not be a sustainable pace, you're living beyond your means, and you're shipping more features than your team can afford, and eventually you're going to have to pay the piper. PETE: So do you have advice for teams who are – I mean, I really agree with that, that sentiment. If sometimes you do need to accrue this debt, that you should have a plan in place to pay down your credit card or whatever. For financial advisers, they're always talking about ways to do that. What guidance do you give for teams on how to make that plan? One of the things that I see teams really struggle with is they say, “Yup, we know this is bad. We’re taking on some technical debt here; we’re going to clean it up after this deadline or release or whatever,” and then they never quite get around to doing it because the business is always asking for more features. So, how can they fix that issue? JARED: The best way to pay off debt is to not accrue debt. Go listen to Dave Ramsey and everywhere he talks about living out of cash envelopes, do cash accounting. If you can’t afford it, you don’t get it. When you're creating stories for the business to evaluate, don’t make one story or one feature that says, ‘here’s the test, here’s the automated test,’ or ‘here’s the refactoring’ and ‘here’s the features’ are two different things, make that one story. And if you present the business, ‘this is the cost of the feature,’ then they’ll make an accurate assessment. If you get someone who quite [inaudible] isn’t technically qualified to tell you how important the tests are, they're always going to choose the cheaper, faster route, which will be incurring the debt and next week, they're always going to want a different feature; they're always going to want more work. My best advice to anybody in that situation is to simply say, “This particular feature isn’t going to be a two-day feature and then two days of tests. It’s going to be a four-day feature or points, or however you happen to measure things in your org. make it a single unit of work to do things the right way. And occasionally, if you have a pressing release, a pressing deadline, yeah, you can cheat from time to time, but when it becomes a lifestyle, we come back to sustainability – it’s not going to be sustainable. Do you like where you work? Do you like the people you work with? Don’t put yourself in a situation where it’s going to implode. Make sure it’s going to last. PETE: I agree with that. I think that’s a really good sense of building your quality in, the same as a carpenter doesn’t ask you if you want five nails, or 10 nails – they put 10 nails in because that’s the safe thing to do. But there are occasions, right? You gave the examples of there's a trade show coming up and to see who comes in and leans on you real hard and says, “Hey, you know I know you're going to have to cut some corners here. It’s critical for the business,” blah, blah, blah. At that point, how do you set yourself, how do you embrace the fact that you're going to accrue this debt but deal with the consequences and actually clean up after yourselves? What are some tricks to make sure that you don’t just leave that debt lying around? JARED: Make a deal with our manager, stakeholder, customer – whoever the person is that’s pushing – tell him you want 20%. You'll get 10%, but 10 is a good number. You want 20% of every subsequent sprint, iteration, marathon, mile marker – whatever you call it – you're going to get 10% of that time to pay the debt off. And don’t refer to it as bad; don’t use the term ‘code smells’, don’t say it’s inefficient, don’t use all the fuzzy words developers use when we talk to each other. You don’t talk about ‘code smells’; managers manage your money, so you present it as when we’re doing maintenance, it’s going to take significantly longer to add more features if this is in place. It’s going to cost us more to fix bugs, it’s going to cost us more time to onboard people, it’s going to cost us more time to fix, to add, but try to put it as much as you can in terms of dollars, because that’s what most managers are trained to understand, and it’s the language they speak. A lot of times, we try to settle things in technical terms; we tell them the architecture is messy; we tell them that the ‘code smells’, we tell them that things are bad and they go, “So?” I've literally heard business people behind closed doors mocking developers talking about their code smelling. I have heard them laughing at the terms we use, and at the time I was really insulted, but can I stepped back and said, “No, we’re asking them to speak tech, and they don’t speak tech.” So if you're trying to get this paid off, find a way to present it as in it saves time, it saves money, it enables us, and present it that way. Does that make sense? PETE: Yeah, that’s really great advice. That’s really, really good advice, talking to them in their language. JARED: I know developers who have said, “He’s my manager, he has to reach me,” “She’s my manager, she has to understand me,” – if you're the one that wants the communication, you have to reach them. PETE: Yeah, and I think also for non-technical people, it feels like they're always hearing developers talk about how x, y, z is inefficient, or the code’s a mess or whatever and frankly, as developers’ [inaudible] our personality is we kind of strive for perfection and are always aware of things, the stuff [inaudible] we kinda whine about a little bit, I think. It’s really important to [inaudible] this stuff in ways that distinguishes, you know, this is serious, this is going to slow us down from, “Oh, I really wish I had time to reimplement all this stuff because it would be fun to rebuild it again from scratch.” JARED: Mm-hm. I've been told before that no developer ever comes into a code base without wanting to rewrite it. [Inaudible] At that time I was insulted, because I wanted to rewrite the code base I was in and it happens a lot! PETE: I like telling developers that when they're starting on a new project. Like, for the first week or month, whatever, at this green field, you're going to love it. You should be spending all of your time trying to figure out how to keep it, that green field. And that goes back to the tech debt thing – every time you take a little short cut, you're getting closer to that stage you're in before you started this green field where you were grumpy about the big mess that your legacy code base was in. If you're not actively working to pay down this tech debt that you're accruing, then you are building a legacy code for yourself. You're building your own [inaudible]. JARED: I like that, How to Keep the Green Field Green – there's a good fertilizer joke there somewhere, but. [Laughter] I like that. CHUCK: So how do you resist the urge to do that thing where you rewrite instead of fixing the tech debt? PETE: I think that’s a really good question because I've seen teams do that where particularly –. Something that I consider an anti-pattern is teams that say, ‘we need to do a tech debt sprint, or a tech debt something or other thing.’ I call it a functionality vacation, where they're like, ‘okay, we’re going to take a vacation from doing [inaudible] work, so we got all this tech debt that we need to pay down.’ And what tends to happen is they pay down the stuff that they find personally irritating rather than the stuff that’s actually slowing people down. So they’ll spend 50% of their vacation cleaning up all the code that actually doesn’t need optimizing or no one ever really works at it anymore, but it’s just been really irritating everyone because, “Oh I can’t believe we’re still using C++ over here and we haven’t imported it to Ruby, so let’s spend 50% of our time glossing this thing over that’s solid, that works, and that no one ever needs to change anyway.” I think that’s the real challenge for teams, to not get caught in that trap of, “Oh, we’re paying down tech dept so we’re allowed to fix whatever we wanna fix.” JARED: So when you do a tech vacation, who picks the features? Do you just turn the developers loose and say, “Go nuts! Fix what irks you?” PETE: That’s the risk, right? I think if you do that without some forethought then things are going to go wrong. JARED: I generally have a tech lead employee that would be the person who would filter that sort of thing. It’s because of exactly what you just said: people tend to fix what annoys them, not necessarily what the team needs. I tried to have the team present those and say, “Okay, what do you think we should work on?” but I still want a big-picture person there who’s technically competent, technically savvy, that can pick and choose what the teams work on the same way they would during a regular iteration. PETE: I think, ideally, teams should avoid those kinds of blocked out chunks of work partly because of this issue of working on stuff that’s fun to work on and partly because if you present this to the business, it does not sound like a good deal, right? Yes, you can catch it in terms they understand, but you're still basically saying, “We wanna spend a week kind of sharpening our tools rather than building a functionality that you feel is urgent for us to build right now.” Now if you bill that tech debt removal into your standard iterations, or your standard cadence, then I think you get two things. Partly, you're kind of getting closer to that thing of doing, building quality and not kind of accruing this thing in the first place and presenting the cost, the real cost of the business, rather than the kind of discount it costs because you're running out of debt in the background. And also, if you do that, the tech debt that you're paying down tends to be on code that you're working on, which tends to actually be valuable stuff to pay down. So that creaky, old C++ code that no one touches anymore – yes, it would be great to rewrite it, but actually no one touches it anymore so it actually doesn’t – that debt isn’t as painful or is not dragging you down as much as the boring-but-always-in-your-face tech debt of an inefficient algorithm or something that doesn’t [inaudible]. I don’t know; I can’t think of a good tech debt example. That’s my take, because it’s better to kind of build this stuff in, and pay down the stuff that’s in your face rather than kinda sitting back and trying to decide what would be valuable to pay down. JARED: Absolutely. If you have a technical debt sprint, forget even trying to sell a “vacation” to management because then we’re back to the language discussion again. But if you know there's a tech debt sprint [inaudible] every month, every two months, then it’s okay to accrue that, right? Because I know I'm going to have a [inaudible]; I’ll have time to fix it later, which would actually get skipped from time to time [inaudible]. I don’t like the assumption that we’re accruing debt. I much prefer the cash envelope metaphor, “If you can’t afford it, you don’t pay for it.” I know I'd love a flat screen monitor or flat screen TV, 3D or whatever, but if I don’t have the cash in hand, I'm just going to [inaudible]. PETE: That’s a really [inaudible]. I think all of this stuff comes down to setting the right culture inside of the team, the culture of building quality and kinda frankly, being a professional. A good chef doesn’t leave old vegetables lying around on his counter; he cleans up as he goes along because he knows that it’s important to doing a good job. I think a good software engineer should be doing the same thing. JARED: I think it may have been stolen from someone else, but I've heard Neal Ford quote this one more than once. He said, “In the future, not writing unit tests will be considered malpractice for software developers,” will be considered a professional – I'm drawing a blank on the exact term, but you know what I'm saying. It’s malpractice; it’s professional negligence. I think a lot of the things that we refer to as technical debt today will be viewed in that way as the industry matures. I was reading just this morning on – gosh, what was the guy’s name? The guy, the doctor back in the 1800s, Ignaz Semmelweis, introduced the idea that doctors should wash their hands. He saw mortality rates with infants: 12% at one hospital, 2% at another. The difference being over here they delivered cadavers and went straight to deliver new babies. And, big surprise, they got sick and died – 1 out of 10 babies. When he introduced the idea that people should wash their hands, which now we take for granted, was he hailed as a hero? No, he was fired. He was a pretty smart guy; he shut up about it, but apparently some of his students and followers latched onto the idea, pushed it back out in public, and so other doctors had him involuntarily committed to an insane asylum where he was then beaten to death. Maybe we shouldn’t push tech debt. [Laughter] I think a lot of the things, for instance, in the early days of extreme programming, people talked about test first, test rhythm, and people were mocked for it, right? You're getting pairing, what? You're getting half the work at twice the money. I think as our industry matures, that 12% infant mortality rate is going to be similar to the project failure rate that we now view as normal. We look at roughly – I mean, there's a number of different statistics, but long-term projects have a 50-90% failure rate when they're longer than a year, and we think that’s normal. There's so many good practices that a lot of us know – heck, I'm as bad as anyone else. I know what we should do; I’ll come in, I’ll jokingly tell my family, “My job is to come in, watch other people work and criticize them” and of course, when I come home, get mad when my teenage daughter does the same thing to me, but you know, I'm not paying her. [Laughter] I think a lot of us know what to do and we simply choose not to do it, and it’s okay because we’re used to a 50-90% mortality rate. At some point, we have to step back and pull out the Einstein quote of “doing the same thing we always did and expecting a different outcome is insanity.” My doctor has a sign in her waiting room, it says, “Hope is not a strategy.” But how many times do we go into a planning meeting for a new product and say, “Hey, everything we did last time – this was wrong, that’s wrong, the other’s wrong – but this time, we’ll do better. Yay! Go team!” What are we going to do, the same thing? But it’ll work better this time. Why? Because we’ll try harder! I'm ranting now, but you get the idea, right? We know a lot of the good practices that we should be doing, but as an industry, we’re just not used to doing it. We’re too insulted by the thought that our hands might be dirty, so we’re not going to wash them. ANDREW: I think that brings me something I want to ask you about and that is, most of the things that we talked about so far are certainly applicable to any kind of software development, but for iOS in particular, I wonder what you see teams doing wrong, perhaps [inaudible]. The reason I thought of that is because I think unit testing is still much less common among iOS developers than it is among some other people working in other languages and on other platforms, and so I'm curious about iOS-specific trouble that you see in terms of technical debt. JARED: I think you hit the biggest one right on the head – it’s test automation. It’s harder to do in iOS. It wasn’t baked in at Apple early on; it seemed to be making strides to catch up. But in the early days of iOS testing, the testing was hard; it was very difficult to do and a lot of the developers who came from Ruby, who came from Java, who may have had that bug in the past came over and the impedance mismatch was so high they dropped the habit. I know very few iOS teams that have a good automated test week and about as many that have a continuous integration system. Those are two areas where that side of the fence is just not where it needs to be. ANDREW: I agree with you. The team I work on – I'm actually really a Mac developer – but we have just a little bit of unit testing in some of the most critical parts of our code, but for the most part we don’t have any automated unit testing and continuous integration is something we’ve struggled with for a long time. JARED: And it’s not that you don’t see the value; it’s that the tool doesn’t make it easy, and that’s just what it comes down to. I mean, I've been doing this for a long time; I've sold my first program back in ’91. I was still in college at the time, but I've been here, there and yonder. I came up to SmallTalk where the first [framework came from and moved over to Java – saw a JUnit, known about it but not used – and when Ruby came on, when you generated a Rails project, Ruby on Rails project, it put testing stubs right in there; it’s part of the default template. When you generate an empty project, the testing is already baked in. The command line tool [inaudible] runs those tests, you have units, integration – the whole nine yards, and big surprise, you make it easier to do and a lot more people did it. And a lot of the really good testing frameworks that we had in other language, other ecosystems, are migrated from or direct copies of a lot of the Ruby and Ruby on Rails tools. In iOS, it wasn’t baked in; it was harder to do, and we’ve lost a lot of those really good habits. And that’s a hard problem to tackle. PETE: So that’s kind of true, and kind of not true, because there is actually unit testing stuff baked into XCode – it’s just crappy. It’s just that Apple don’t really get how unit testing works because I suspect they do mass unit testing then – well maybe they don’t do less than the average iOS developer, but they certainly do less than the average Java developer, I would guess. So I think [crosstalk], I think it’s partly – it comes down to a cultural thing, but I think that the main challenge that we have is something that I think we have really, the iOS community has really evolved in the last few years on is getting that culture of testing. I whine about it a lot and kind of [inaudible] about it a lot, but I'm actually really positive that as we get a lot of people coming in from the outside of the Apple bubble, they come in and they say, “How do I do testing in this environment?” and someone says to them, “Oh, this is how you do it.” And they say, “Well that’s crazy; I just came from a place that’s much better. Let me try and improve that.” I think that it will improve over time, but I think we have a long way to go. ANDREW: I think you're right. I've been doing objective-C development since before the iOS boom and I really do think that the tools have gotten better even though XCode has a long way to go, but I think it’s mostly because of the influx of people that are coming from platforms where unit testing is really just ingrained in the culture, and so I hope that continues. PETE: What I would love, love, love to see is for Apple to do – I see Apple as where Microsoft was in kind of the mid-90s maybe where there was lots of this stuff going on outside of the Microsoft ecosystem and they started noticing and saying, “Hey, look at what people over there ORMs, people over there are doing unit testing, we need to get on that bandwagon.” And so they built all of their own ORM systems, their own unit testing systems. They weren’t as good because they fundamentally didn’t really understand a lot of how to do that the best way; they didn’t have those best practices, right? But eventually, I think Microsoft [inaudible], and started embracing the community outside of them and bringing them in and kind of making it bigger, [inaudible] whatever. What I would love to see is I would love to see Apple not building their own freaking CI server, but actually working on how to integrate things into all of the existing CI servers, right? We don’t need another CI server. To their credit, the one time I've ever seen a WWDC tour, that wasn’t just talking about Apple technology was the one where they showed how to set up a unit testing with a basic CI system with Jenkins. So maybe things are moving in the right direction . JARED: Think about the company that you're talking about, though. From what I've heard, from an outsider’s view – I'm not a hardcore objective-C or iOS programmer. There were two groups within the company – one was pushing Ruby, one was pushing objective-C; the open source versus ‘we own our own language’ camp one. It’s going to be more difficult for them to look beyond that not invented here, and don’t get me wrong, it seems to be working, but you're right – they could be using their time a lot more efficiently and a lot more effectively if they were picking those best-of-breed tools and just integrating them, instead of starting from scratch. Which brings me around, you guys have a platform. You have this nifty, little podcast, right? Several people at work I know that are not iOS developers, I asked them about it and they were like, “Oh yeah, iPhreaks, I listen to them” You have a platform [inaudible] to help teach people how to do unit testing. [Inaudible], test drive and integrate, I mean, is that something you could do a show on in the future? CHUCK: Yeah, probably. One thing that I've run into though with the podcast is that – I mean, we can talk about the benefits, and that works really well for the podcast – but actually teaching people how to do it, a lot of times that's a little bit trickier with just audio. So it becomes a lot easier when you have video, where you can actually get in and say, “Look, here’s how you write a unit test with this class or this ViewController or this whatever” and then turn around and “here’s how you write your integration test to make sure that it flows correctly and does the right things.” PETE: I agree with that, Chuck, but I also think that there's a lot of kind of theory, there's a lot of discussion that you can have around the theory behind things and kind of the best practices for getting started. Because what I see a lot of teams do is they start off with great intentions where you're going to get setup with CI, we’re getting set up with unit testing, but they take a few wrong turns, which, for those of us who have gone down this path before, are obvious, but they're not obviously wrong turns the first couple of times you make them. And then two weeks later, or two months later, no one’s bothering to run the CI anymore because the tests are too slow, or the tests are hard to maintain, and so they start [inaudible] all of these things that I see lots and lots of people do and it’s fine, it’s kind of part of that learning curve of learning this. It’s simply a tough, new skill to learn. I think there's lots of things that we could talk about in terms of how to get started and what are obvious pitfalls, and what are obvious – what are ways to kind of slowly succeed, rather than succeed fast for a while and then fail, and then get burned and tell your friends in a year’s time, “Oh, yeah I was at this company where we did unit testing and it was a total failure and it would never work in any situation.” That’s the thing that frustrates me; people have tried and managed to take a few wrong turns, and they become kind of proponents of cowboy coding because they’ve managed to make a few mistakes. Not make it intro a unit test with this framework, make it an experts’ panel, to say don’t use this unit testing frame work, use that one. Don’t use the built-in CI sever, use Jenkins. Walk them down that path; that might work well on the podcast format. CHUCK: Yeah, definitely. And the thing that’s interesting is that I think a lot of times we do forget that learning to test is a lot like learning to program, and so we made it through the pitfalls, and we learned how to write code. We learned, we made it through more pitfalls and we learned objective-C, if it wasn’t our first language, and all of the different frameworks are available in iOS and so why should testing be any less difficult? JARED: That is a good point. That is a really good point. CHUCK: Yeah. JARED: Well, if somebody on the panel today wants to do this in a video format, one of the other things that I do that I didn’t mention in the intro is I'm the video editor for the Pragmatic Programmers and I'm always looking for new topics and new authors. I'd love to do a video presentation of your favorite unit testing toolkit, your best objective-C CI integration. CHUCK: Cool. JARED: Left-field advertising pitch, sorry. [Laughter] PETE: Just smack it in there, it’s good. JARED: No, I think you guys can do a lot with the panel. It sounds like you’ve already got a one guy who’s got to talk after it. CHUCK: There you go. Alright, we’re getting close to the end of our time, are there any other critical things that we haven't talked about yet relating to technical debt, credit card debt, or whatever you wanna call it? JARED: One of the biggies that a lot of people are aware of that recognizes something needs to be refactored or rewritten and they won’t ever get back to it, and that's just something that it’s nice to mark. Even if it’s just a comment in the code, a to-do that says, “Look at this algorithm; I think it’s taking too long. Look at this method; it’s got five exit points. I'd rather have one.” It’s just something that a lot of people don’t really mark; they just notice that it’s messy and then move on, whereas if you put a little bread crumb in the code, and then next week, five other co-workers, over the next – maybe not in the next week, over the next month – are in the same place and see it and agree with it and endorse it and strengthen it, then you know you’ve got a good candidate for when you are paying off that 10% per iteration. But all in all, I think we’ve covered a great deal of the material pretty well. CHUCK: Awesome. Alright, well let’s go ahead and get into the picks then. Andrew, do you wanna start us off? ANDREW: I think Pete really wants to go first. CHUCK: Pete really, really wants to go first. Go ahead, Pete. PETE: You could’ve gone first. ANDREW: You’ve  revealed that I was secretly lobbying. PETE: Okay, first pick is actually totally relevant to that last comment from Jared. One of the techniques that we normally bring to teams is this idea of a tech debt wall. So we like sticking lots of sticky notes everywhere and one thing we do is we set up one of those flip chart, kinda stick-on-the-wall flip charts, and have two axes: kind of cost of not fixing it, and the cost to fix it. Whenever we identify one of those bits of tech debt as we’re creating it or as we discover it or as we have in conversation, we’ll write a little sticky note describing the tech debt and anytime we put it somewhere in that quadrant. So things are really causing us a lot of pain but would be really expensive kinda go up on the top right. Things that are expensive to fix but aren’t causing us that much pain get up the bottom right and it’s kind of, obviously, when you do have some spare cycles and you wanna work on that tech debt or if you're either doing one of these tech set things, you have a good place to start. You start at the top left where the stuff that’s going to have a big impact [inaudible] fix it, but it’ll be pretty cheap to fix. It’s interesting, I've always wanted to do a stop-motion video of these things over time. I kinda feel like watching the tech debt waves come and go through a team would be an interesting visualization. There's one [inaudible] pick and then my other pick, which is absolutely non-technical is a clothing company in San Francisco called Betabrand. They make really funny things; they make like bike to work pants that have pockets in the back, that when you pull them out they're reflective so that you don’t get run over by cars. They make disco pants, which are like disco balls, but they are pants. They make an executive hoodie, which is a pinstriped, wool hoodie and it looks like a fancy suit jacket. They're just kind of a fun company; their website is kinda fun to browse around, so check them out. I like them. ANDREW: Do you have some of the disco ball pants, Pete? PETE: I'm wearing them right now. [Laughter] Every day. [Laughter] No, I don’t have the disco ball pants but I do have the executive hoodie and I get great pleasure from it. CHUCK: Alright. Andrew, what are your picks? ANDREW: I've got two picks today. First is Slack, which is a new web app for sort of a team chat, kind of. It’s like Campfire or – what's the other one that came out pretty recently? I can’t remember, but they’ve done a really good job. A lot of features –you can have multiple channels, and private messaging, and they’ve done a good job handling screenshots. And we’re not using it at work, but I've been using it with some friends just to chat about development and have liked it a lot in the last couple of weeks. And then my second pick is furbo.org, and this is Craig Hockenberry’s blog. Craig is a developer at the Iconfactory; he’s the guy who wrote Twitter, I think, among other things. His blog is one of the most consistently helpful blogs that I read. He’s always posting really practical things to solve problems that he spent a day debugging that kind of thing. And those are my picks. CHUCK: Awesome. Alright. As many of you know, I really enjoy listening to audio books. I just finished one, it’s called So Good They Can’t Ignore You by Cal Newport and he basically talks about the passion hypothesis for finding a job that you love. It’s really interesting, the way that he attacks the problem of finding a job that you love. I really enjoyed it; I felt a little bit funny about it initially because he basically says, “Looking for that job that you're passionate about is not the right way to approach finding a job that you love,” but the thing is is that the more I read the book, the more I realize that what he was talking about, as far as how to find that job that you're passionate about really is the way that I got into doing what I love, and so I loved it. In the end, I really enjoyed the book. So you really can’t find the job that you love, it just takes a little bit of work and you have to do some of these things that he talks about. So, I'm going to recommend that book. Another pick that I have – sometimes I have to run Windows on my Mac and I've really, really been liking Parallels, it’s just really a heavy way to go. So I’ll put links to those in the show notes. Jared, what are your picks? JARED: I’ll have to counter your Parallels with VirtualBox, which is an open-source and free virtualization tool, came through, was purchased by Sun, now it’s Oracle. I like it a lot more than Parallels for several different reasons. I used to be a Parallels guy, but I'm all for virtualization. The other thing that I've gotten into lately is the virtual currencies. Bitcoins had a lot of drama lately, I'm actually kinda stuck on Dogecoins. So if you know the Dogecoin meme, someone – or doge meme – someone invented a coin in December as a joke, that has gotten a lot of traction and is one of the only coins that hasn’t been fluctuating with all the Bitcoin drama. So just Google Dogecoin, there are some fun stuff there. I also, you mentioned audio books, two of the ones that I've hit on recently that I like were Steffan Noteberg’s Pomodoro Techniques of the Pragmatic Programmers and another one that just came out called The Healthy Programmer by Joe Kutner. Both were topics I thought I was fairly conversant in and both had a lot of information that I didn’t know, so that’s good stuff. The last completely known technical thing that I've gotten into that I almost didn’t bring, but I thought you'd get a kick out of are jeeps. Not the new ones that look funny, but anything on Craigslist. My daughter’s 15 years old and she bought an old Beater Jeep last year that was in rough shape, and I've discovered the entire Jeep subculture. There are user groups, parts shops – it’s just a lot of fun to play with them. CHUCK: Awesome. JARED: Slightly non-technical thing. CHUCK: Yeah, we interviewed Joe Kutner. It was a Book Club book for the Freelancers’ Show. JARED: Ah, I didn’t realize that. CHUCK: So folks can go check that out, we’ll get a link to that in the show notes as well. But yeah, thanks for coming, Jared. JARED: I appreciate it. It’s been a fun conversation. CHUCK: Yeah, appreciate you taking the time to spend with us. ANDREW: Thanks Jared, it’s been great. CHUCK: Oh, I need to mention the Book Club book – Functional Reactive Programming on iOS by Ash Furrow, and we’re going to be interviewing him on April 1^st, which means that you, the listener, will get this about a week later. So go pick it up; we’ll have a link to it in the show notes, and thanks for listening.