Minimizing technical debt before launch or major milestones is huge because, on occasion, that debt can compromise all future estimates/dates/milestones if it i

Minimizing technical debt before launch or major milestones is huge because, on occasion, that debt can compromise all future estimates/dates/milestones if it is not addressed. I think developers, including myself, like to get things right before launch because fixing it after launch is harder, if not impossible once other emergency/technical debt comes in and starts layering on top of that debt. If this goes on for 1-2 cycles, before long your app, backend and internals look like a shanty town that no developer wants to enter. Sometimes I wish code was visual like buildings, you could more easily see quality that way. Mostly though you have to believe in your developers/engineers that what they are building is a mansion/building you want not a shanty town dwelling that is held up on duct tape and silly putty, yet the technical pressure/debt put on is largely coming from someone who can't see the visual representation of the system. Developers can only be MacGyver for so many release cycles before instability strikes the system down if management is not careful. There will always be some amount of technical debt but developers do love to get things done and out the door as fast as possible. We like to do so with a minimum amount of technical debt as it is a constant battle against time/market/cost with quality.