Cruft Budgeting

Your users need functionality rapidly. You can see what needs to be done to get from point A to point B and how to do it, but you know that it will not be elegant and you will have to ReFactor quite a bit to simplify.

Can you get the system running with the new feature quickly? Should you? You know that CruftMultiplies. If you build on top of a portion of the system that is not well factored it will be that much more painful to refactor later. What do you do?

Examine the ChangeVelocity of the portion of the system you need to modify. Is there any reasonable chance that you will need to build there before you get a chance to refactor? If not, then go from A to B. You have a budget for the work in that area. If it is a high velocity area, don't do it! You will incur serious pain later. -- MichaelFeathers

A similar (identical?) concept is TechnicalDebt.