In this podcast episode, Shane Hastie, the Lead Editor for Culture & Methods, chatted with Dustin Thostenson about recognizing and addressing technical debt.

Shane Hastie: Hello, everyone. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I have the pleasure of speaking with Dustin Thostenson. Dustin, you’re based in the East Coast of the USA, right?

Dustin Thostenson: Actually, I’m in the Central region. Specifically, I’m in Iowa, right in the middle of what’s often called flyover country.

Shane Hastie: And I’m as usual, joining from New Zealand. Let’s start with an introduction. Who is Dustin Thostenson?

Dustin Thostenson: Thanks for having me. Who’s Dustin? That’s a great question. I’ve spent the last 25 years in the tech industry, yet it seems my kids are responsible for my gray hair, not the technology. Over the years, I’ve engaged in software development, taught at higher education institutions, and taken on various coaching and consulting roles. Currently, as an independent consultant of 15 years, my primary focus has been on delivering high-quality software and helping others not only enhance their skills but also improve the dynamics within their teams. My passion lies in ensuring that others get to experience being part of efficient, effective teams that empower them to excel and please their clients.

Shane Hastie: Dustin, we’ve crossed paths at different industry events over the years. Today, I wanted to discuss the methods you’ve been recommending for managing technical debt. Can you share some of these strategies?

Dustin Thostenson: Certainly, throughout my career, I’ve noticed a recurring challenge with technical debt across various teams. Technical debt, to me, represents anything that disrupts the flow of your team’s ability to deliver efficiently — be it convoluted codes, unstable builds, or sluggish pipelines. My approach to addressing technical debt extends beyond just technical solutions; it requires a strategic review of both technical and human elements at individual, team, and organizational levels. While there is no magic product to eliminate technical debt instantly, a blend of technical improvements and better interpersonal interactions has proven fruitful in my experience.

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?

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 lack the necessary experience, how can I acquire it?

Dustin Thostenson: There are several resources available that can help. For instance, Josh Kerievsky’s book Refactoring to Patterns effectively connects with Martin Fowler’s concepts on design patterns. It also aligns well with Michael Feathers’ insights in Working Effectively with Legacy Code. Reading these can help you learn to name what you observe and master various refactoring strategies that might bridge the gap to where you need to be. That understanding and ability to identify issues are crucial.

Furthermore, Emily Bache has put together a valuable collection of code katas on her GitHub repo. I’ve personally found practicing these katas to be highly beneficial, both individually and with teams. By regularly working through these exercises, adjusting code, and navigating solutions, you develop the knack for common shortcuts and refactoring methods that makes solving problems more intuitive.

Shane Hastie: Indeed, there are robust resources for recognizing and learning these patterns. In my view, there is a significant underappreciation for the role of patterns in programming education today. Am I being too critical?

Dustin Thostenson: Sometimes in discussions about software architecture, there’s mention of ‘ivory tower architects’ who over-apply design patterns, swinging the pendulum too far. If repetitive problems arise, maybe a factory pattern is needed, or if reporting processes become recognizable, perhaps a strategy pattern could help. Identifying these patterns can present a new perspective on code structure.

It’s not about having a perfect design full of patterns, but about recognizing inefficiencies and using your toolkit to propose changes, like, “What if I try this approach?” Knowing the patterns by name enhances communication with your team. Sometimes an effective solution turns out to be a known pattern discovered serendipitously, like the chain of command pattern, which also turns out to have a name.

Shane Hastie: And how about implementing these concepts at the team level?

Dustin Thostenson: It’s challenging to impose change on others, often backfiring. Realization that one can only control oneself is crucial; acknowledging this helps others perhaps follow by example. Demonstrating changes in personal habits can be inspiring, making it easier for others to adopt similar behaviors and join in naturally. This can enhance the team dynamics and lead by influence.

I’ve observed that some teams establish “kata time” as part of their daily routine. Their agreement is to dedicate 15 minutes post-stand-up to engage in a kata for relaxation and skill enhancement. This isn’t about tackling the usual business challenges but rather about enhancing their teamwork and communication through structured coding exercises. Such practices help in refining essential skills, much like practicing basic sports drills helps in actual games. This way, when real challenges arise, the team is better prepared to handle them efficiently without the usual sprint-end pressures.

Shane Hastie: What if I lack the authority to lead this initiative? How can I inspire my teammates to adopt this practice?

Dustin Thostenson: Influential leadership often transcends formal roles. According to Jerry Weinberg, “Consulting is the art of influencing people at their request.” This resonates deeply with me. Even without a leadership title, your impact can still be profound. By fostering a positive environment during collaborative tasks like pairing, you can demonstrate productivity and mentorship. Introducing efficient techniques or tools could inspire your peers to adopt similar practices. At the end of the day, your reputation within the team is built on their direct experiences with you rather than your external accomplishments or accolades.

Shane Hastie: You mentioned it so eloquently before, the unclear boundaries and the vast community around us who have high expectations and are frequently disappointed because things aren’t progressing as hoped.

Dustin Thostenson: And significant expenses are involved.

Shane Hastie: Indeed, we are investing a lot of resources. It’s consuming a considerable amount of time. We need these products because we aim to achieve ambitious goals within the organization, but the outcomes are not aligning. How can we, as technologists, persuade the broader community to join us on this journey?

Dustin Thostenson: Many of us in the technology sector have dedicated our learning to technology. We pursued education in this field, we stay updated by listening to technology podcasts, reading books, watching technology-related videos, and querying platforms like Stack Overflow. However, we often overlook concentrating on the people. What makes sense to us might not resonate with them. Recognizing that everyone has their own motivations can be the first step in bridging this gap. Consider that they are also striving to satisfy their customers, answer to a board that demands returns on investment, and meet marketing deadlines. Understanding that they face their own pressures and responsibilities, what truly matters to them and what do they genuinely need?

Oftentimes, if you listen and reflect their concerns accurately, such as explaining that quality issues lead to customer dissatisfaction and additional bug reports, which delay further development, you demonstrate understanding from their perspective. This acknowledgement helps them see that you grasp the situation. Additionally, I used to advise being clear and concise. Yet, a friend corrected me during a presentation, suggesting “succinct” as a better term. This involves understanding how data transitions through stages—data, information, knowledge, insight, wisdom—and recognizing patterns and connections leading to insights, outcomes, or solutions.

This approach helps to quickly address their inquiries effectively using familiar language without oversimplifying, thus keeping their engagement without overwhelming them. Respecting their knowledge and backgrounds ensures effective communication and collaboration.

Shane Hastie: These are not typically associated skills for technologists, nor are they commonly trained in. How can we develop these skills effectively?

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?

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:

Engineering Excellence: Declan Whelan on Technical Health, Agile Practices, and Team Culture

Engineering Leadership: Balancing Autonomy, Growth, and Culture with Michael Gray

The Evolution and Challenges of Engineering Management

The State of Engineering Management in 2024

Welcome to DediRock, your trusted partner in high-performance hosting solutions. At DediRock, we specialize in providing dedicated servers, VPS hosting, and cloud services tailored to meet the unique needs of businesses and individuals alike. Our mission is to deliver reliable, scalable, and secure hosting solutions that empower our clients to achieve their digital goals. With a commitment to exceptional customer support, cutting-edge technology, and robust infrastructure, DediRock stands out as a leader in the hosting industry. Join us and experience the difference that dedicated service and unwavering reliability can make for your online presence. Launch our website.