Techniques to Tackle Technical Debt with Dustin Thostenson

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I'm sitting down with Dustin Thostenson. Dustin is East Coast USA, Dustin?

Dustin Thostenson: Central. We're in the flyover country, Iowa.

Shane Hastie: I'm as normal, coming to you from New Zealand. My normal starting point is who's Dustin?

Introductions [01:04]

Dustin Thostenson: Thanks for allowing me to be on here. Who's Dustin is a great question. I have been in technology for 25 years now, but I owe all of my gray hair to my kids. I didn't have gray when the kids came around, so I don't think it was the tech. Been in the field for 25 years and I've had a lot of different experiences, a lot of software development. I've been able to teach at a university or a community college. I'm not going to try to inflate it. Did that for a decade, for nights and evenings. I've done different types of coaching roles, a lot of consulting, and I've been an independent consultant for 15 years. My focus really has been on being able to do the work and to deliver high-quality software. I've also found my greatest joy is being able to help others not only improve their skill set, and also improve the teams that they work on. I want to make sure that other people have the chance to be on some really high-performing teams, enjoy their work and delight their customers. I think they deserve that.

Shane Hastie: Dustin, we have bumped into each other over the years at various events, but the thing that I wanted to talk to you about today is you've been talking recently about techniques to tackle technical debt. What are some of these techniques?

Common patterns of technical debt [02:20]

Dustin Thostenson: For all the teams that I've worked on, I've found a common theme, and it seems like most people are struggling with tech debt. When I talk about tech debt, what I really just mean is that ability to have flow. Your team's ability to deliver. All those little things that slow somebody down, complex code, flaky builds, slow pipelines. I view those as all things that can be improved and things that we've seen improved with other people. That's my more general view of tech debt. A lot of times I've seen people try to look a purely technical approach or a tool approach to solve that thinking if we just implement this tool or change these practices or get better PRs, we'll solve the problem.

Or maybe if we just get time, just quit developing for new features for a month and we'll just fix all these problems. What I've actually seen is there's a lot of different things that can be done to help this problem that sometimes people don't really think about. I've been collecting some of my experiences and the experiences of other people and I've really found that there are technical and interpersonal things that people can do at different scales, things that somebody can do for themselves, for their team, and also for their stakeholders or the greater company that they work in. I don't have one simple answer though that just buy my product and it's all fixed, unfortunately.

Shane Hastie: There is no tech debt magic wand. Who would've thought?

Dustin Thostenson: Not yet. If I could box it though.

Shane Hastie: Self, team, and stakeholders. Let's dig a little bit into self. Individually, what are some things that the individual contributor, developer, architects, on a team can do to help reduce technical debt at their level?

Things an individual contributor can do [04:20]

Dustin Thostenson: I think when it comes to any type of problem, the first step is usually acknowledgement and identification. A lot of times we've got people who are rushing to get things done and they might not see how the decisions they make today are going to impact tomorrow. Sometimes they might not recognize that the way that they're coding a solution has a formal code smell name to it and they might not recognize that they're creating a temporal coupling smell. It makes sense to include this logic right here because the spec says it does this and then it does that and then it does that and then it does that. People might just put those things right at that level instead of recognizing we've got PDF exports over here and CSV exports and recognizing that there are different responsibilities that could be separated that could help make things a little bit easier, and that goes with the code or the pipeline. It's really agnostic to technology. I think recognizing that a decision being made now could have an impact. Sometimes that just comes with experience, but there are ways to get it.

Shane Hastie: If I don't have the experience yet, where do I find it?

Useful resources [05:38]

Dustin Thostenson: There are some books out there. Josh Kerievsky has a book called Refactoring to Patterns, and that bridges with Martin Fowler's book on design patterns. It bridges nicely with Michael Feathers' book on Working Effectively with Legacy Code. There are some publications out there where you could just read it and then start learning the names for the different things that you're seeing and then possibly learning some of the different refactoring techniques which could allow you to take steps to get over to there. That helps with the acknowledgement of it and the identification to have that trigger to say, wait a second, something's not right here.

Then Emily Bache has got a great GitHub repo with a bunch of code katas, and that's the thing that I've done for myself a lot. It's something I've done with teams. Just being able to grab some different code katas and practice cloning the code, making a bunch of changes and seeing if you can go through all those steps. That can make a huge difference because now when you see the problem and then you've been practicing the muscle memory to hit the keyboard shortcut, to extract the method or to rename something, it becomes a lot easier. It doesn't have to be a dedicated effort. You can just do it as you see it and then it just happens.

Shane Hastie: There are good solid resources people can dig into to identify those patterns. Personal opinion, I see far too little recognition of the importance of patterns in developer education today. Am I being harsh?

Recognising patterns [07:21]

Dustin Thostenson: I don't think you are, and I'm assuming that sometimes when you would bring that up, people will bring up the edge case scenario of the ivory tower architects who try to implement every pattern, and there's definitely a pendulum that goes back and forth. If you find yourself doing the same thing and it's causing a problem, maybe introduce a factory. That's been a solved way to do it. Or if you're having to kick out reports and you recognize there seems to be a pattern here, maybe you could add a strategy pattern and maybe just seeing what that pattern is allows you to see a new way that the code could look.

I don't think that you have to come up with all the patterns and have everything designed perfect, but when you see that something isn't working, sometimes it's good to have that in your toolbox, so you say, "What if I try this?" If you know the name of it, then you can communicate with your teammates more quickly. Sometimes you might just stumble upon something that makes sense and find out later on, "Oh, that was a chain of command pattern. It made sense, and I guess it has a name".

Shane Hastie: Those are some things that individually I can do and digging into my own learning about patterns and starting to recognize patterns and use them. What about at the team level?

Things we can do at the team level [08:35]

Dustin Thostenson: Sometimes people will try to inflict help on others, and that doesn't usually work so well. I've come to the realization that the only person I can control in my life is myself, and I struggle to do that. I would be in much better shape and probably running a 5K tonight instead of sitting down and playing on my computer. I think it's a good acknowledgement to say I can only control myself. Once somebody does that, and once somebody does start to practice those behaviors, it does become easier for other people to emulate. Sometimes people might see what you're doing and they might want to do that because it looks more enjoyable. If you have people who are willing to go with you, that's when you start leading that influence. You make it easy for people to join.

I've seen teams have team katas as a team agreement. They say, "After stand-up every day, we're going to spend 15 minutes and we're just going to have fun. We're going to work on a kata. Yes, I know that we write code all day, but we're not going to be focusing on the business problem that we're trying to solve. We're going to focus on the pattern or the muscle memory of it. We're going to focus on mobbing so we know how to talk to each other and we know how to communicate what we're thinking better". Sometimes just those little things where you practice the dribbling and the shooting, and when you practice those little things, then when it's game time, it all comes together easier without the pressure of we have to get this story done by the end of the day because the sprint is over.

Shane Hastie: What if I'm not in a position to lead this team? How do I bring others on this journey with me?

Leading through influence [10:15]

Dustin Thostenson: A lot of the best influence doesn't come from positional hierarchy. You can be an influencer without having that formal title. One of my favorite quotes is from Jerry Weinberg where he says, "Consulting is the art of influencing people at their request". That makes a lot of sense to me because if I'm doing work on a team and I don't have a tech lead or any formal title, if the team is open to pairing, then I want to make sure when people are pairing with me that they're having a good experience, that we're getting stuff done, we're delivering a quality product, and maybe they learn some things.

Maybe they see a keyboard shortcut that they didn't know before. Maybe they recognize a different way to write tests quicker and faster where it's actually preferable to create a test and reproduce the problem. It doesn't even matter at the company or even internationally, nobody cares what conferences I've spoke at. Nobody cares if I was an author or anything. What they care about is what they see and what their experience is. If they're enjoying your time, they might want to try that too, and if they don't, that's their choice.

Shane Hastie: Stepping out into the wider community, you said it beautifully earlier, the gray area, the mass community around us who have high expectations and are often frustrated, things aren't going exactly like we would hope.

Dustin Thostenson: We're spending a lot of money on it.

Shane Hastie: We're spending a lot of money. It's taking a lot of time. We need these products to help the organization achieve some great goals, and it's just not happening. How do we as technologists bring those people along with us?

Communicating the value of reducing technical debt to non-technologists [12:07]

Dustin Thostenson: I think a lot of us in technology have learned technology. We went to school to study technology. We listen to podcasts and read books and watch YouTube videos on technology. We search Stack Overflow to understand technology. What we don't do is we don't always focus on the people and what makes sense for us doesn't always make sense for them. I think that there's a couple of steps that you can take to help bridge that. Again, going back to that concept of acknowledgement, acknowledge that they have motivations. They have customers they're trying to make happy. They have a board of directors that's expecting ROI. They've got marketing which has timelines. I think it helps to just understand this person has pressure on them as well too, and they have a different type of responsibility, so what is it that they care about and what is it that they really need?

Oftentimes, if you listen, and you can now also parrot it back to them to say, "Oh, so all these quality issues are causing a problem with you because the customers aren't happy, and now we're having to create all these defect bugs, which is pushing off additional work that we can do today. If we didn't have all these defects, then we could probably make marketing happy because we can hit the conference that they were going to announce all the new features at". If you can understand it from their point of view and reflect it back to them, when they hear you say it, they know that you understand. The other thing is, I'm going to laugh about this a little bit, I originally was telling people you need to be clear and concise in that messaging. You need to figure out what details do you really need to share and only give the deeper details if they ask questions.

The reason this tickles me is because the first time I talked about being clear and concise, a friend in the front row said, "I think you mean succinct". There's a diagram that I've seen that has different pictures of data, information, knowledge, insight, and wisdom, and it talks about the granularity of the data and being able to add meaning to the data and have relationships with the data. Then when you get an insight, to be able to recognize this thing over here eventually connects to this other part over here, whether it's an opportunity, an outcome, problem, solution, but there's a relationship through that. That to me is what I try understand so when I talk to somebody, I can get to that point quickly. Then when they say, "But how do you go from point A to point B?" Then I need to make sure that I can tell that story quickly using the words that they understand.

Not talking down to them, but addressing it for their needs. Then when they want more information, you start getting into the relationships and maybe schedule an offline meeting, but just be able to communicate with them so you can keep their attention and not force a memory overload error or make them feel dumb. Just treating people with respect, understanding that they have a different background, and that's fine. They could do the same thing to you. I found some of those things in my long-winded answer about being succinct have been very helpful in bridging that relationship and making sure that we're all working towards the same goals.

Shane Hastie: These are not skills that one stereotypically technology folks are known for, and also, they tend not to be skills that we are trained in. How do we build those skills? How do we build that muscle?

Building communication skills and taking responsibility [15:44]

Dustin Thostenson: I agree with you. For me, I think part of it was recognizing when things weren't going well for me to stop blaming others. That guy is Peter Principled, and that person is just dumb. They don't get it. I realized, again, I can't control them. If I had to go in a time machine, is there something I could have done differently? I used to think about that when I would drive home from work. I'd reflect on my day and go, "If I had that meeting again, what would I do differently?" That reflection, I think helped me acknowledge that some things weren't going perfect and that maybe if I tried something different, there'd be an opportunity. That was the first real awakening for me. Then I've had some different consulting opportunities where all the coaches were hanging out in the same spot and we would complain to each other at the night and then they said, "Yes, you're right. This client, they're screwed up. Yes, they should do something about it".

Well, guess what? They did, they hired us, so what are we going to do? Sometimes they would be preaching to the choir, "Oh, they need to do this, this, and this". Then they would stop themselves and say, "Oh, I'm just preaching to the choir". I said, 'No, you're practicing. You're taking all these ideas that you have in your head and going through them, so the next time you do that, you're going to give a quick answer". Sometimes having targets, I'm mentoring a kid who just graduated college and he was going to have a meeting with a vendor in the university for his product, and I said, "Well, the first thing is you have to make sure that you're all in alignment, so don't talk about how you're going to do something. Talk about what you want to do and how that aligns".

He did. He goes, "Well, that worked really good". I mentioned, "Now you want to listen to what they have to say because if they're going to give you access to an API, they're going to have some real concerns, so you need to hear that and you need to acknowledge it. Then you need to make sure that you're going to do something about it and keep telling them about it". It was some simple checklist, but it was something that was at the top of his head that he was at least looking for. I think the big thing for me is this all really came down to, I had learned about the responsibility process eight or 10 years ago, and I had studied with Dr. Christopher Avery for a bit. That really helped change my life because I realized that when these things happen, we're going to go through some different stages. Our first stage is were going to deny that there's a problem.

Yes, well, I don't see a problem at all hitting that production delivery date. Then when something happens, we start telling ourselves stories about blame, and you look at everybody else as they're the reason for it, but you're giving up all of your ownership. You're giving away all of your power to do anything about it. After that, you get into justification where you start telling yourself, Yes, but we always miss production dates and we never do anything right here. Again, you're telling yourself stories about why it's okay for this bad thing to happen. For myself and others, I see people get into shame a lot where you're basically blaming yourself. At least you're taking a little bit of ownership for it, but it's not healthy.

Sometimes you might work nights and weekends because you feel like you're obligated to the team that if you were better, they wouldn't have to do it, and you're going to work as hard as you can, but eventually get into that responsibility mode where you get to look at the problem objectively and you get to decide, how would I like to see this come out? You get to make a choice, and it's not responsibility as in accountability, but it's about your ability to respond. I think that with individuals and the way that they work with the teams and the way that they work with their stakeholders, you get to analyze what's going on and make that choice, how can I best respond to this in order to have the best possible outcome for me and all the people I care about?

Shane Hastie: It's a hard ladder to climb, the responsibility process, isn't it?

Dustin Thostenson: It is much easier when you spend months or years looking at other people and being able to frame it. It's much easier when you see somebody denying a problem right off the bat or when you hear them talking about a problem and using blame. When you start to have that framing and you see the pattern that other people go through, then eventually you start wondering, well, maybe I'm like everybody else. Maybe I'm just as human as everybody else. Then just like seeing the bad code and recognizing this is a trigger, this is a code smell, this code smell has a name, you can start to recognize that own trigger in yourself and go, "Ooh, trigger happened. Now do I react out of habit or do I take a moment and add a little bit of space to decide what am I going to do with this trigger?" It's a lifelong journey for me, I'm sure, but it's one that I like.

Shane Hastie: You quoted Jerry Weinberg, and I want to go back to one of his sayings, "No matter what you think the problem is, it's a people problem".

Dustin Thostenson: It's always a people problem. Absolutely.

Shane Hastie: If you don't think it's a people problem, it's a people problem. As technologists, how do we get better at working with people?

No matter what you think the problem is, it’s always a people problem [20:57]

Dustin Thostenson: I think that the acknowledgement of that quote, Jerry's stuff is so amazing because it's so easy to read quickly and gloss over it. I think just acknowledging that, that is the case, changes what we see in the world. It changes what we're looking at. If we think that it's a problem with the old framework or an old tool or bad code, that's all that we're going to look at. Jerry also said things are the way they are because they got that way. If you're looking at the code and you come in and this is crap, and this is crap and junk, junk, junk, junk, junk, the people who wrote that might be in the room and they might have done the best that they could at the time.

It's very possible that they were new and they didn't know a better way or they were covering for somebody who was on maternity leave and they had twice the workload and half the timeline. There's a lot of reasons why things get to be the way they are. It's never mal-intent. Usually, it's not mal-intent. I think recognizing that and understanding what would have to happen in this environment for these things to come true gives you a little empathy. Then if you start looking at that and saying, "Okay, well, this is what we have today. What are people willing to do? How are we willing to try some different things?" Now you start looking at the way a company is organized.

Are they functionally organized where you have a UI team and a backend team and a database team and a security team? Recognize, well, if we were to make a change, what would have to happen? Who would have something to be lost if we did this? Who's losing their team of 20 or 200 people? What does that do for them? Who's losing their pride because they were the master of the system and they've always been that person, and now they might not have that credibility or the ego anymore. When you start looking at some of those hidden motivations or at least asking questions, you're going to find out what is possible and what might not be possible yet, and then you can start figuring out how do we apply the tech to work within these constraints instead of just applying a template that just throw Kubernetes on everything and it'll work.

Shane Hastie: That's been some really useful resources there. Some great pointers. If people want to continue the conversation, where do they find you?

Dustin Thostenson: They used to be able to find me on Twitter, but now I guess it's called X. You can find me there as Dustinson. I love connecting with people there. You can also catch me on LinkedIn, and I have been trying to build up my own website a little bit more, trying to put some more content in some of the recordings of the talks I've given. I love going to conferences and still meeting people in the old analog way.

Shane Hastie: Dustin, thanks so much for taking the time to talk to us today.

Dustin Thostenson: It's been an absolute pleasure. Thank you for all the work that you're doing to bring this out to the community and make a more positive impact. Appreciate that you're doing these things. Thank you.

Mentioned:

• Dustin Thostenson on LinkedIn and X
• Book: Refactoring to Patterns
• Book: Working Effectively with Legacy Code
• Emily Bache GitHub code katas repo
• Christopher Avery Responsibility Process