We talk about testing, code quality, and coverage. But why? Because we want to spend less time dealing with technical debt and more time creating new technical debt (aka new features). Many times, we think we made the obvious smart decision only to regret it later; you discovered you’re damned if you do, damned if you don’t. Should you write a monolithic app or tangle of microservices? They’re all terrible worlds we’ve made for ourselves. Having maintained, inherited, and created several large Django projects, I hope to share my experience so you don’t have to go through the same pains I did. We’ll start off with a few minutes covering basics like testing, coverage and how they relate to the long term health of a project. Now, everyone knowing the same terminology, we move on to learning to recognize the many early warning signs and smells of excessive technical debt. The most important thing, and most of the material is about setting up the organizational structure for dealing with technical debt: code review, continuous integration, rotating developers (no silos), tradeoffs, making sure you have processes for onboarding new developers, and strategies for documentation. It’s changes like these that end up keeping things moving, not writing “better” code. Finally, we’ll wrap up with a few minutes talking about Django specific tips: don’t customize the admin, tricks for naming things, signals, organizing tests, and more. Much of this comes from my time at The Texas Tribune, where we needed Django projects launched the next day, all while maintaining a 6 year old Django project.