
In this episode of the podcast, Shane Hastie, Lead Editor for Culture & Methods, discusses with Declan Whelan about aspects such as technical health, relevant metrics, contemporary technical practices, code stewardship, and the cultural elements that contribute to successful engineering teams.
Shane Hastie: Hello everyone. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I’m delighted to be speaking with Declan Whelan. Declan, welcome and thank you for joining us.
Declan Whelan: It’s a pleasure to be here, Shane, great to connect with you again, and I appreciate the invitation.
Shane Hastie: Absolutely, it’s been some time. While we know each other well, many in our audience might not be familiar with you and your contributions. Could you introduce yourself, Declan?
Declan Whelan: Fair point indeed. Residing in Canada, my background is in electrical engineering, though my entire career has revolved around software development. I always sought out roles that kept me entrenched in coding. Throughout my career journey, I’ve held roles as a coach, an individual contributor, and as a CTO for two startups. I thrive on technical challenges within agile environments and continue to engage in training, coaching, and coding whenever possible.
Shane Hastie: Throughout the years, you’ve emphasized the importance of strong technical practices within teams, and also the concept of technical health over technical debt. How would you define technical health?
Declan Whelan: That’s an insightful query. To address this, it’s helpful to start with the term “technical debt.” This term was coined by Ward Cunningham around the late 1990s. It describes the trade-offs in software development where short-term gains are achieved by cutting corners, similar to taking out a loan—these gains, like immediate cash from a bank loan, allow for immediate benefits such as quicker feature delivery to clients. It’s important to understand that while these shortcuts may offer immediate relief or progress, they do come with a future cost. Technical health, conversely, focuses on practices that maintain sustainability and efficiency in development processes.
I discovered that the metaphor was quite effective, yet it also had its limitations like any metaphor. My initial aim was to cast technical debt in a more favorable light because traditionally, debt carries a negative connotation. We associate being in debt with negativity, and escaping it is seen favorably. However, in technical spheres, you’re perpetually in debt—there’s always more to be done. Thus, I thought introducing a more positive terminology would be beneficial. This led me to coin the term “technical health” as an alternative way to view technical debt.
Since adopting “technical health”, I’ve noticed some unexpected advantages. For instance, consider personal health in relation to world-class athletes participating in the 2024 Olympics. Their definition of health vastly differs from that of everyday people who might focus on maintaining fitness and controlled blood pressure. This demonstrates that different environments and contexts demand varying priorities and standards. By using “technical health,” I aim to broaden the perspective on technical matters, highlighting what’s crucial for achieving desired business outcomes. Everyone has health, and unlike debt, it’s intrinsic to our existence and systems.
Moreover, in our endeavors to build systems, there’s invariably something we wish we had done differently or would improve if given another chance. This is the essence of the term “technical health.” I envisioned it as a more comprehensive, relatable concept that encourages proactive, positive actions. That’s the thought process behind the term and its implications. Does that resonate with you?
Shane Hastie: Technical health encompasses every system and results from their respective environments. You mentioned the impact of systems; how can we enhance these systems to improve our products’ technical health?
Declan Whelan: Indeed, an excellent question. Recently, one of my clients raised a similar concern regarding the effectiveness of their technical practices. Many organizations turn to static code analysis, examining metrics like cyclomatic complexity or code coverage. While informative, these aren’t directly relevant to customers. A significant shift I attribute to the DevOps movement is the emphasis on customer-centric operations. Teams now bear direct responsibility for customer deliverables. Concerning your question about improving technical health—the first step is measurement. The DORA metrics are particularly insightful here. For those unfamiliar, DORA metrics include deployment frequency, lead time for changes, change failure rate, and mean time to recovery. These metrics, bolstered by DevOps initiatives, have emerged as crucial for organizations performing well.
To delve deeper into improving technical health, consider adopting the DORA metrics. By measuring these, you can begin to identify and address bottlenecks—perhaps aiming to enhance deployment frequency. Technical debt thus manifests as factors hindering efficiency, while technical health broadly indicates systemic functionality. Whenever this question is posed—as you rightly did—the answer lies in initiating robust measurement protocols. DORA metrics stand out as reliable indicators of technical prowess.
Recently, my interest has grown in understanding value streams and implementing flow metrics precisely. In current SAFe® frameworks, there are six specific flow metrics that I am beginning to explore. Currently, I am engaging with a book titled Flow Engineering by Steve Pereira, which details these. This source aims to broaden the scope beyond traditional DORA metrics to emphasize the overall workflow.
For instance, the DORA metric ‘lead time for change’ measures the duration from code commit to production deployment, excluding the initial stages such as business analysis and product requirement gathering. A more comprehensive metric could be the overall cycle time or lead time from the customer’s initiation to endpoint. Contrary to focusing solely on internal measures like code coverage, the key aspect should be the frequency of delivering value to customers—directing attention towards external impacts.
Shane Hastie: This indeed marks a transition from internal metrics, such as cyclomatic complexity, to more customer-centric metrics akin to DORA, covering even the comprehensive cycle from start to finish.
Declan Whelan: Absolutely, the industry giants might be leading with these practices, but many firms find it arduous to implement both shift left and shift right strategies. This plight isn’t rare, as I’ve noticed significant divisions still exist, for instance, between QA and development teams. Even if these teams share common goals, their organizational structures, including separate reporting and performance evaluations, often undermine their unity. Despite efforts to shift left, many organizations still grapple with this transition, suggesting a persistent challenge in achieving true integration. How do you perceive this situation?
Shane Hastie: I do see it and I just wonder why. What is it in our systems that is making that shift left, that true value stream, the true team, what’s making it so hard?
Declan Whelan: I can only report on what I’ve seen, but where I’ve seen it, one thing is definite: I worked with a company that was 150 years old about 10 years ago. At that time, I was collaborating with their development team and wanted to engage with their testers. Making an appointment to meet them alone was an ordeal, and upon meeting, I was immediately asked for a project code to bill the meeting to. There was significant resistance to me speaking with the testers due to the different reporting structures within the organization. Fast forward about seven years, and although I no longer needed a project code to speak with a tester, the reporting differences persisted. Even as they were located in the same team on an organizational chart, they still managed separate work streams. For a true shift left, it’s imperative for QA and developers to work together closely. Yet, organizational barriers between QA and development remain a problem, particularly in more traditional, regulated sectors like banking, telecom, and insurance. These barriers might take these companies another decade or more to dismantle.
Shane Hastie: Can they afford to wait a decade?
Declan Whelan: Well, in Canada, all of those types of companies do quite well. They don’t suffer. They’re probably more profitable than they’ve ever been, in general. Maybe that’s it, they could afford to do it. Shift right, I don’t have a lot of experience with shifting right, which is basically being able to chaos monkey things in production sort of idea. I would say, yes, until you can shift left, I don’t think you’re ready to shift right. Until you can reliably design, build, release, yes, it’d be awfully difficult to get into putting in appropriate safeguards to shift right in production. I still think we’re a ways from that in many places that I’ve worked, for sure.
Shane Hastie: If we go back to the beginnings of some of these practices, extreme program. Kent Beck gave us some great ideas in 1999, 2000. There was a period when XP was held up as this is the way to build software, and it seemed to then fade away. What’s happening with those practices now?
Declan Whelan: I grew up like you did, I think I got exposed to Agile through XP, so extreme programming and the technical practices in particular that it brought were very different than Scrum. I would say in my view, Scrum, because it specifically hasn’t had an opinion on technical practices, in fact, it’s the world of work, it’s not just software development. There was no guidance from Scrum or Scrum.org or any Scrum material around technical work. What I think has happened, and by the way, yes, so SAFe® and other frameworks, they’ll usually have something about technical and they’ll almost always include extreme programming as the technical practices. Where I’ve worked in SAFe®, I’ve worked in four different SAFe® organizations, I’ve never seen the extreme programming technical practices used, although they’re actually part of SAFe®. I think with Scrum, it doesn’t matter. They had no opinion.
With SAFe®, even though it does have an opinion, what I’ve seen is it’s so low in the order of things that they should take care of, there’s so much to save. It’s just another line item of things that you may or may not do or could not do. I’ve just seen just companies get overwhelmed with SAFe® so much that they actually don’t get to the technical practices. I was at the Agile 2024 conference in Dallas, and I had exactly the same question that I had you had. I was like, “Where is Agile going and where is extreme programming in particular going? Because I like to work in extreme programming. It’s the way I choose to work.” I think one of the silver linings on what I would say is the downturn on Agile, which is the people feeling Agile has perhaps run its course.
We have certainly reached a point where Agile methodologies are widely adopted, often placing companies into challenging scenarios. Many of these difficulties arise from inadequate technical practices that lead to mounting technical debt, overwhelming companies over time. Traditional companies, in particular, find it arduous to maintain frequent release cycles, such as every week or two, without revamping their technical practices to support faster delivery. This lack of robust engineering practices arguably contributes to what some perceive as the decline of Agile.
My perspective gained a positive boost during a session I attended in Dallas on FAST, which stands for fluid scaling technology. This session emphasized the importance of integrating extreme programming practices at the core of technical strategies. The potential revival of these rigorous technical practices seems promising, especially as traditional Agile methodologies haven’t always delivered expected outcomes. I remain cautiously optimistic about the future of technical practices in Agile implementations.
Shane Hastie: In developing a foundational engineering team, what are the essential technical practices that should be adopted?
Declan Whelan: The landscape of effective technical practices has evolved since their initial conception by Kent Beck with extreme programming. Originally, extreme programming emphasized four main practices: pair programming, test-driven development, refactoring, and maintaining a simple design. Today, pair programming might extend to include ensemble or mob programming. Test-driven development remains somewhat controversial, yet it is a well-acknowledged practice. Refactoring is widely recognized and practiced to various extents across the industry. Lastly, adhering to the four rules of simple design continues to be vital.
When it comes to coaching or training teams, I typically introduce essential practices which significantly enhance the implementation of Scrum. Adopting these four additional methods could greatly benefit teams. However, this does not encompass some of the more contemporary practices associated with DevOps, such as achieving continuous delivery and enhancing observability in production systems, which are crucial in today’s technological landscape.
Modern developments have introduced tactics like feature flags to support continuous delivery, marking a significant evolution from traditional practices like extreme programming. Additionally, there’s increasing emphasis on sustainable service management, a concept I’ve been engaging with more deeply recently. This involves thinking beyond the immediate scope of building software to ensuring that the services we create are maintainable long-term and can be smoothly handled by future teams.
This shift towards thinking about system architecture with a focus on service-oriented approaches and long-term stewardship marks a significant addition to conventional technical practices, suggesting a broader change in how teams structure and manage their development work.
Shane Hastie: We also observe architectural trends that seem to oscillate from one extreme to another, such as the transition from large monolithic architectures to microservices, and then to an overabundance of microservices leading back to distributed monolithic structures.
Declan Whelan: Most of the companies I’ve worked with have really gone down the microservices or service-oriented approaches, for sure. I think one of the problems with service-oriented architectures that I’ve seen is that usually people will design their service boundaries pretty early. You have to, if you’re going to spin up these services. You have to make decisions about what is their domain and what do they do.
It turns out with service-oriented systems like that, changing those service boundaries is going to be where you’re going to have a lot of friction because whoever’s using your service, those changes would potentially need to be coordinated to roll those out. I think architectures that allow you to defer your service boundaries or encapsulate your service boundaries perhaps within a monolith, seem to me to be good approaches. I’m not an expert.
One technology I’m always drawn to for this is Elixir and Erlang because they were built so that when you build something, it’s not just a single service, but it’s actually a set of cooperating services, making it much easier to roll out changes that might touch multiple parts of your system. Outside of say, Elixir or something like that which handles that internally would be moving towards mono repos where even though I’m changing multiple services, I just have one mono repo, and so when I make my change, I can actually change and eventually, deploy systems together or close together in time.
A mono repo with a single monolith which might have different services is certainly a direction that some companies are going. I’ve not actually worked, well, I’ve worked with one client who was just in the middle of doing a mono repo, so I haven’t actually seen how well they work in the wild, but I can see the value in it for companies struggling with microservice boundaries.
Shane Hastie: This is the Engineering Culture podcast, we’ve been talking a lot about practices in here. What are the cultural influences that allow us to get into good technical practices? What is a good team?
Declan Whelan: For a good team, I’m not sure that technical practices would be different, or if I have a good team, it wouldn’t matter whether they were doing technical work or not, I guess is what I’m trying to say. It would be about certainly the collective, having an idea that we’re in this together and the extreme programming had the idea of whole code ownership. It’s our team that owns this code, so having that idea of we’re in this together, I really liked the idea of stewardship from, I think I mentioned it already from Matthew Skelton and the team topologies, that idea that we need to take care of this not just now, but for ourselves in the future. We don’t want to be woken up at 3:00 AM with beeper calls if we can avoid it, so that idea of high-quality work. I love the word stewardship, really taking care of the products that we’re releasing and recognizing that we’re not just building for now, but we’re building for the future as well.
Your horizon might differ, it could be three months or a year or whatever, but we need to be cognizant of not accruing too much technical debt by taking care of our future. Certainly, I’ve always been on a culture perspective, this sort of learning organization ideas from, just rereading the fifth discipline actually, and that idea that we’re always, especially in our field in tech, things are always changing, so we need to be in a position and a culture of continuous learning.
That’s one thing that I’ve always been attracted to the agile extreme programming practices, because they really focus on using pair program and ensemble programming to share and learn together as a team. The rising tide raises all boats. We’re all going to learn together and that we learn from each other. I may know some keyboard shortcuts that you don’t know, Shane, and Shane, you might possibly know a little bit more about business analysis than I do.
We could benefit greatly from engaging collaboratively, embodying a team culture that embraces true teamwork. In many organizations, I’ve observed a preference for collaboration over mere cooperation and coordination. Teams often excel at coordinating tasks—splitting up stories and responsibilities—but separate when it’s time to tackle the issues alongside one another. However, those teams that lean into collaborative methods instead of just coordinating, tend to cultivate a more positive work culture.
Shane Hastie: Diving deeper into pair programming and ensemble programming, which are fundamental in extreme programming, we know they improve product quality based on various metrics. However, the challenge remains in the perception that it involves doubling the workforce for a single task. How do you counteract that perception?
Declan Whelan: There’s certainly evidence supporting the effectiveness of practices like pair programming, though it’s not overwhelmingly strong. The general consensus is that while pair programming may not increase productivity per se, it typically reduces defects. Therefore, the output quality is higher, although it doesn’t necessarily speed up or slow down the process. I suggest simply giving it a go. If it proves viable, continue; if not, adjust accordingly. Mob programming represents a bigger challenge, as it requires broader team involvement, which can be tougher to achieve. The key is to experiment for a sufficient period, perhaps six weeks or more. In my coaching practices, I encourage frequent, dedicated sessions to tackle coding issues as a group, which helps refine skills through continuous, practical engagement. Instead of relegating improvement to sporadic sprints, integrate regular, actionable experiments to facilitate quick learning and adjustments.
Shane Hastie: An experiment. Declan, thanks very much. A lot of good advice, good ideas in here. If people want to continue the conversation, where do they find you?
Declan Whelan: Probably the best place is on LinkedIn. It’s just Declan Whelan, all one, on LinkedIn. I’m easy to find. It’s funny, Shane, I tore off my badge in half. Apparently, I do not know how to separate a beer ticket from a conference pass. I was ripping out a drink ticket and I ripped my ticket in half, so it only said Declan. Then I realized, that’s probably all I need in the Agile community. It’s Declan Whelan, and LinkedIn is the best way to reach me.
<strong Shane Hastie: Wonderful. Thanks so much for taking the time to talk to us today.
Declan Whelan: Oh, it’s always a pleasure, Shane. Always lovely to chat with you.
Mentioned:
Engineering Leadership: Balancing Autonomy, Growth, and Culture with Michael Gray
The Evolution and Challenges of Engineering Management
The State of Engineering Management in 2024
Â
Continuous Delivery, Psychological Safety and Inclusive Leadership in Software Engineering
Â
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.