Most engineering teams maintain their own balance between feature work and technical debt. This varies according to culture, funding phase, and even the product area. With little provocation, most engineers could probably rifle off a laundry list of items they’d like to tackle to improve their workflow, speed up processes, or just maintain their own sanity. However, work on technical debt for too long and you’ll lose sight of customer focus, neglect important features, and your engineers may begin to miss the shiny feature work that elevates their careers.
So how do we decide when dealing with tech debt is worth it? On the ground, many developers struggle to find the balance between striving to improve existing code and letting good enough alone by accepting certain shortcomings. As a new developer to a team it can be difficult to understand existing strategies and patterns that are sometimes flat out bad (and often openly acknowledged as such). Often the result of tight deadlines or unclear specifications, even the best developers write code they later look back upon and shudder.
Come learn how to develop your own framework for addressing technical debt as a company. I will discuss strategies for prioritizing technical debt, ways to “stop the bleeding” of bad practices, and potential complicating factors.
