Apart of the suggestion here, you have a problem in " but due to the nature and timeline for the project cannot do it for each and ever commit of course". If t

Apart of the suggestion here, you have a problem in " but due to the nature and timeline for the project cannot do it for each and ever commit of course". If the time is so tight that you can dedicate time to fix stuff (including the code quality) then any of the suggestion here are DOA. Remember: If you want to chop wood for 10 hours, use 8 to sharp the axe. Code, code, code, code non-stop is as efficient as chop wood without sharp it after a while. Dedicate time to improve the code quality ALWAYS pay off. Think: "I'm time constrained, so continue the death march until we finish" ALWAYS make the project take longer. ---- A good idea is STOP each week, review the tasks, ask where are the pain, where is the code that is becoming a mess, what is complicated, then FIX that. Decreasing code/clearing it in the short AND long run will be a time saver. Encourage change when the purpose is quality. Not stick to code/design that is a pain. Stop each week to breathe and see if move forward as now make sense, or is better to kill a portion of the code and rework it. This is specially important when the TIME is critical. When time is not critical, you can do bad code because, hell, you can take the time! But when you have not time, any bad code is slowing you. Then make this clear to the team. Not be yourself the only that code review. Everyone can do it. Take control when deploy. Not when your customer say so. Be predictable (ie: Always deploy in the start of the week, never at the end).