1. Prevention
1.1. Tougher stricter code reviews
1.1.1. Reject pull requests if code is not clean
1.1.2. Regardless of project deadline
1.1.3. 2 reviewers per code review
1.2. Workshops and presentations on code quality
1.3. When a bug is found write an automated test to reproduce it, fix it, then run the test to make sure it passes.
1.4. Spend time daily reviewing code so that the team gets to know the standard.
2. Cleanup
2.1. Boy scout rule: Always leave the code cleaer than you found it
2.2. Monitor performance and refactor when user experience decreases.
2.2.1. Load times
2.2.2. Queue consumption rates
2.2.3. Set up an alert level for each flow and when it hits take action
2.3. Create technical debt roadmap and work towards reducing it
3. Definition
3.1. Technical debt is the difference between what was promised and what was actually delivered
3.2. Promises are rarely spoken out loud
4. Causes
4.1. Lack of knowledge
4.1.1. How does good code look like?
4.1.2. How big should a method be?
4.1.3. Why does good code matter?
4.2. Doing things in a hurry
4.2.1. During a big project small gains by rushing to develop don't speed up anything
4.2.2. Bad code slows everything down because it makes you repeat steps and think about too many things at once
4.3. Not taking pride in your work
4.3.1. Programming is a form of art
4.3.2. There is always a way to solve a problem the fun part is finding the best solution and getting as close to it as possible.
4.3.3. Your code is your legacy.
5. Next steps
5.1. Techincal dept reduction roadmap
5.1.1. Create it
5.1.2. Inform developers and let them populate it whenever they find something to improve
5.1.3. Work on it on every sprint
5.2. Turbo charge code reviews
5.2.1. Team leader: 1hr/day
5.2.2. Architect: 1hr/day
5.3. Code quality presentations in each team
5.3.1. By whom?
5.3.1.1. Team Lead
5.3.2. Topics
5.3.2.1. Unit tests
5.3.2.2. Clean code
5.3.2.3. Programming principles
5.3.2.3.1. DRY
5.3.2.3.2. KISS
5.3.2.3.3. SOLID
5.3.2.4. Naming
5.3.2.4.1. Functions
5.3.2.4.2. Variables
5.3.2.4.3. Classes
5.3.3. When?
5.3.3.1. During working hours
5.3.3.2. Mandatory participation by all team