We have started a Refatoring of the code base for Crowd Fusion.  This version of the Code is barely 6 months old but was prototypical from its birth.  Ryan is taking the lead and being sensitive to the core principles, our Element Controllers are restrictive, but allow future extensibility without conflict, and need to remain intact.   While working through some of the framework design flow were discussing a great post about 'professional PHP developers' and I thought about a missing component to this.   A professional PHP developer has undergone numerous refactors, and they'll be able to talk about the pitfalls.

Great programmers are never happy with what they wrote yesterday.  So I'm trying to come up with a formula about when you should refactor and if you can tell the quality of a coder based on their desire to start over.   Using myself as the measuring stick (great coders are also very egotistical) we are 6 months into design and the code base needs an overhaul that will take 2 1/2 weeks.  So there it is.. if the your dev team is itching to rebuild your code base and the time it will take is more than 1/10 the age of the code, you've either got really crappy code or you need a new team. 

There are tons of great resources to help you know when to refactor and the pitfalls to avoid scattered across the web.  The question should never be if you should take a fresh look at your systems, the question is when.  If you aren't spending atleast 10% of your teams hours cleaning up your Objects, reducing redundant code and cleaning up design flow life you will come to a point that new development is nearly impossible without adversly affecting the rest of the system.  Every hour of new dev will come at the cost of 10 hours of debugging.  Spend 10% of your time now to avoid it being 90% or your time later.  If you are getting pressure from the suits, have them call me .. I've made this mistake before I'll explain to them the consequences.