Summary

Managing technical debt in (Django) Projects by Chris Chang

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.