Effective product engineering requires a continuous focus on both innovation and stability. While exciting new features are essential for growth, so is maintaining a healthy codebase. This is where the concept of technical debt comes in.
Moving Beyond the Broad Term: Precise Language for Technical Debt
Technical debt can encompass various activities, from preventative maintenance and regular updates to rearchitecting components and clarifying ownership. Using more specific terms like these helps us create a shared understanding within the team and with stakeholders.
Tech Debt Without Blame: Reframing the Narrative
It's important to remember that technical debt isn't a mark of failure. Often, these "debts" represent engineering decisions made to deliver a product faster or satisfy other requirements. For example, temporary code shortcuts might have been implemented to meet an aggressive launch deadline. Now, to ensure long-term product success, addressing those shortcuts becomes a priority.
This reframing removes any sense of blame. Our engineers are highly skilled professionals who make informed decisions within acceptable risks.
My friend Steven Langbroek reminded me recently of the retrospective prime directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
-- Norm Kerth, Project Retrospectives: A Handbook for Team Review
I think we all are best served to apply this directive not only to retrospectives and post-mortems but also to viewing past engineering decisions we now consider “tech debt”.
Strategies for a Sustainable Future: Addressing Technical Debt
So, how do we tackle technical debt effectively?
The ideal scenario is to integrate "fixes," "optimizations," or "re-architecture" directly into feature development. While this might extend timelines slightly, it's the most cost-effective approach in the long run. The team remains familiar with the codebase, ensuring it meets both functional and non-functional requirements while remaining maintainable for future work.
However, this isn't always feasible, especially for platform upgrades or large-scale refactoring. In such cases, dedicating a small, focused team to tackle the debt is preferable. This allows for sustained context switching, crucial for efficient code work.
If a dedicated team isn't possible, consider solutions like "Fix it Friday" – a designated time for focused technical debt reduction. Alternatively, some teams use models like Basecamp's "Cool Down week" after each product cycle. The key takeaway is that technical debt work benefits from uninterrupted focus.
Collaboration over Competition: Building a Shared Approach
Budget-based approaches (e.g. 20% tech debt time) can be problematic. They create an artificial division between "product work" (new features) and "tech work" (maintenance). Remember, performance and security improvements often directly benefit users.
Instead of fostering an adversarial stance, let's promote a shared understanding of the product's needs. Just as product managers value legal advice for HIPAA compliance, they should recognize the importance of a secure and maintainable codebase for long-term product health.
By working together and using the right language, we can effectively manage technical debt, ensuring a thriving product and a happy, productive engineering team.
What are your thoughts on managing technical debt? Share your experiences and strategies in the comments below. Let's keep the conversation going and continue building a future where innovation and stability go hand-in-hand.