A quick but valuable technique for keeping technical debt low:
Lots of teams incorporate code review into their process. Some use Github’s Pull Request model, others use Gerrit. There are many options, and which one you use is a question for your team, as long as you’re doing code reviews. Code reviews are great! They help with QA, as well as creating teaching opportunities between team members.
Some teams do very straightforward reviews — each engineer looks at the code and gives feedback according to their own sense of what is good and bad.
This is fine, but there is an opportunity to raise the bar on code reviews.
One technique for making code reviews more valuable is to have a discussion as a team about what you should be focusing on. This doesn’t mean each engineer should give up on their particular flavor of how they look at code, but rather that they should include some of the team goals.
By having shared goals in code reviews, they act as a hook to guide a codebase in a particular direction. Slowly increasing logging, improving performance issues, or improving scalability are the sort of things that are sometimes hard to do in a single iteration or two, but by keeping them in mind during code reviews, it will help direct the growth of the codebase over time.