Podcast Summary
Tech Debt: Outdated technology choices, shortcuts taken to meet deadlines, and changing requirements or new technologies can result in tech debt, impacting a business's financial viability and ability to innovate
Tech debt is a term used to describe various issues that arise in software development over time. John Bevin, a guest on the show, defines tech debt as outdated technology choices, shortcuts taken to meet deadlines, and the need for long-term re-architecting or even re-platforming due to changing requirements or new technologies. He shares his personal experience of building cloud products and the resulting tech debt. The debt can manifest in different ways, from outdated languages or dependencies to the need for complete system overhauls. The importance of addressing tech debt is highlighted, as it can impact a business's financial viability and ability to keep up with new technologies. A friend of the host shared an example of companies re-architecting their software due to performance issues, which can be seen as a form of tech debt bankruptcy.
Maintaining old codebase: Neglecting tech debt in an old codebase can lead to larger problems and unexpected scope creep, making it essential to strike a balance between maintaining and upgrading existing code and introducing new features and technologies.
Maintaining an outdated codebase while continuously developing new features comes with its challenges. Joel Spolsky's famous blog post advises against rewriting everything from scratch but acknowledges the difficulty of balancing the need to adapt to new technologies with the importance of existing code that generates revenue. As the codebase grows and technology changes, maintaining the product becomes increasingly complex. Every line of code is both an asset and a liability, and neglecting tech debt can lead to larger problems down the line. One such problem is the scope creep of requirements and features over time. Making a decision with old code may require upgrading or introducing new technologies, leading to incompatibilities and unexpected bugs. This was the case when we wanted to improve the scripting editor in our SAS product, ScriptRunner. Customers weren't asking for the latest version of Groovy, so we hadn't upgraded. However, when we introduced a new feature requiring the latest version, we faced numerous incompatibilities and had to anticipate and address the bugs carefully to ensure minimal downtime and maintain the high user experience our customers expect. Balancing the need to maintain and upgrade existing code with the desire to introduce new features and technologies is a constant challenge. Neglecting tech debt can lead to larger problems and unexpected scope creep, making it essential to strike a balance between the two.
Technical debt updates: Updating technical debt requires significant resources and communication to justify the investment, but can lead to increased productivity, new capabilities, and better onboarding for engineers.
Maintaining and updating technical debt can be a time-consuming and never-ending process. As technology evolves, so does the need to upgrade and keep up. This was highlighted in a discussion about the challenges of moving away from outdated web server technology and the subsequent need to update Gradle and Groovy. The process can be complex and requires a significant amount of resources, leading to the need for a dedicated team to handle these tasks. To make a case for this, it's important to quantify the impact of technical debt on productivity and business requirements. This can be done by measuring the amount of time spent on these tasks, the frustration level of engineers, and the roadmap of necessary technology changes. It's not just about keeping up with the latest technology for the sake of it, but rather unlocking new capabilities and working more efficiently. Historically, approaches have included drip feeding these tasks into regular work or dedicating entire weeks to tech work. However, the results have varied, with some projects completing successfully and others getting stuck on sharp edges of the codebase. The challenge is to clearly communicate the benefits of investing in these upgrades and make it quantifiable to those in charge of the budget. Ultimately, the goal is to create a more efficient and reliable technology stack that enables faster development and better onboarding for new engineers.
Code as liability and asset: Code requires maintenance and investment for better customer experiences and reliable outcomes. Choices impact architecture and require careful consideration.
Code is both a liability and an asset for businesses. It can be seen as debt that needs to be managed, but it can also appreciate in value as the customer base grows and the software becomes more valuable. It's important for software engineers to focus on the positive aspects of the technology and celebrate the solutions it provides to customers. Every piece of code, including dependencies and libraries, requires maintenance and can impact the overall architecture of the software. Investing in the quality of the software and keeping it up-to-date can lead to better customer experiences and more reliable and predictable outcomes. Some examples of code that has held up well over time include the Wrap Hack web framework and React. However, every choice comes with its own trade-offs, and it's essential to consider the maintenance and potential impact on the software's architecture when adopting new dependencies or frameworks.
Balancing innovation and team needs: Consider team expertise, experience, and psychological safety when implementing new technologies. Trust gut instinct but learn from mistakes. Build psychological safety for open communication and adjust to team culture.
As a engineering leader, it's important to be open to new ideas and technologies, but also to consider the team's expertise, experience, and psychological safety when making decisions. The speaker shared experiences of implementing libraries that didn't work out due to testing issues, lack of understanding, and team resistance. They emphasized the importance of trusting one's gut instinct, but also recognizing that some mistakes can only be learned from experience. Building psychological safety in the team is crucial for allowing team members to voice their opinions and challenges, which is essential for maintaining a productive and happy team. The speaker also highlighted the importance of considering the team's culture and allowing them time to adjust before implementing new technologies. Overall, the takeaway is that as a leader, it's important to balance the desire for innovation with the team's needs and capabilities.
Technology choices, developer experience: Advocating for technology improvements and better developer experience collectively leads to better products for customers. Technology is a people problem.
Improving technology choices and developer experience can lead to a better product for customers. This was a key theme discussed during the podcast. Some engineers may feel that advocating for changes is not their responsibility, but it ultimately impacts the customer. The podcast emphasized the importance of addressing these issues collectively. As the speaker noted, "technology at its base is a people problem." A user named Nikko Skur and IKO KSR were recognized for their insightful question during the show, and the answer to using math.pow with integers in Golang can be found. The podcast was hosted by Ryan Donovan from Stack Overflow and JD Bevan from Scibrona. To learn more, check out stackoverflow.blog, leave a review, or find them on Twitter.