Functional Debt
Thanks to Ward Cunningham, we now have a wonderful metaphor "Technical Debt" which explains the common problem of skipping a little bit of design or missing out that little bit of refactoring to meet a deadline. Whenever we cut corners there is a very good chance we are taking on more and more Technical Debt.
Money to Burn? Invest in Functional Debt
But is there a flip side to this? I think there is and the term I would use is Functional Debt. This is tied firmly in the YAGNI camp and relates to functionality that is developed without a need (or worse still a test). Applying too much design, or developing generic frameworks with no business reason to do so inevitably leads to a solution which is over-engineered. Of course, over-engineering as a term has been around for a long time, but I prefer the term Functional Debt, because this ties it back to money in a similar way to Technical Debt.
Debt is a term that evokes emotion and is easy for people to identify with and it is this capacity of the term to clarify the issue with a certain practise. Over-engineering as a term doesn't evoke the same response and certainly doesn't suggest a loss of money in the same way that Debt does.
There are of course direct, easily measurable costs involved in creating unused functionality and that is the development costs, however, there are many more subtle costs that are easy to overlook. There is the missed opportunity costs associated with not doing the right thing. There is the project overhead costs in maintaining code that is not used. There is the project overhead costs in increased complexity and time for the standard day to day activities of testing and refactoring. There is the increased maintenance costs since it is now harder to understand the code for support personnel...
One of the biggest causes for Functional Debt I have seen is a lack of customer (business) involvement or direction. Left to their own devices, IS departments naturally build overly- complex solutions to simple problems. Without a business value attached to a piece of functionality (actually to a problem that is solved by a piece of functionality) it is only too easy for the IS department to burn money like there's no tomorrow.