💾 Archived View for finn.smol.pub › 1703923824 captured on 2024-05-10 at 10:24:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
(Originally written Wednesday, 5 January 2022)
Although I have had a short career in tech so far, the list of technical debt that Ive come across is not. Even though Ive only had a few odd solo jobs and internships before my current role, which is my first permanent one, there's been plenty of technical debt along the way.
Generally software businesses follow fairly standard Agile practices - in my current role, we have a mixture of Scrum and Kanban teams - and each of these teams have the usual rituals like standup, planning, refinement and retro.
In Agile, product owners are seen as the interface between executives/project sponsors, and the developers. They communicate to the developers the business requirements of a product they're building to make sure its made as the customer needs, and then the developers can communicate progress and technicalities that might come up along the way, and then they can communicate this to the project sponsors.
When developers mention technical debt that they need to deal with, its possible that the product owner can minimise the importance of it repeatedly, often because feature x needs to be developed or deadline y for something is coming up and the customer wants a million other things done by then.
Technical debt cannot be minimised. As it increases, the effects it has compound, and when future code relies on indebted code, the work required to finally deal with it really increases. If the debt is something that isn't feature specific and its effects are present on all new code being written, developers can become hesitant to work on something that could possibly fall over at any point in the future - it could be years away, or it could even happen tomorrow. It can also hinder DX (developer experience) - for example, a temporary stopgap that introduces few extra steps in the debugging and execution cycle could become permanent, and developer happiness can degrade significantly.
Ideally we should have a development cycle that focuses on constantly working down technical debt each day in some way, and occasionally slowing development on new features and stories in favour of this. Product owners can help a lot with this, as they can convince executives/project sponsors that taking care of some of the technical debt is needed in order to start or complete work on a new feature/story. If the product owner is unwilling to do this, then the developers on the team should band together and negotiate that they deal with technical debt before starting on new work.
Sometimes we have to pass up the opportunity to make another dollar in order to ensure long-term developer happiness and stability.