In Agile circles, the bogeyman of Technical Debt – that stuff you incur by not doing it right the first time, pops up whenever you talk about taking shortcuts in the development process. And most of the time, I would tend to agree. Fixing stuff once you are in maintenance mode often is a lot more expensive – especially major design flaws that cross cut throughout an entire application. For example, the cost to untangle the 1st and 2nd layers of a multi-tier application is often very expensive, perhaps in some cases more expensive than starting from scratch. The case against technical debt, is often, a good one, especially if that technical debt carries a high “interest rate” (as in, the debt will cost a lot more down the road than the benefits cost today).
That said, and I ask this as a question, is there such a thing as “low interest rate technical debt” – or what I like to call, a “technical mortgage“? I ask this, because often, getting something, anything, that looks like it might be done is vastly more important than making it perfect. A good starting example would be the “functional prototype”. Most prototypes are designed to be thrown away. It could be said, in theory, that prototype development is akin to technical mortgage – as in – you have something that looks quasi-right at prototype stage, but you are likely going to rewrite a lot of it. There could be other cases where “fast” is more important than “good”.
Hence, my definition of technical mortgage – that is, techincal debt taken on specifically for the purpose of speeding up delivery of a software artifact, when the sponsors of the project agree to the interest rate (aka the risk) that the technical debt represents. While it can be heresy to many people – especially well intentioned people who want to do nothing but a great job, the fact of the matter is that there are situations where the client WANTS us to do a technical mortgage, and it is our duty as consultants to a.) advise them on the risk and b.) if they accept the risk, indulge the request.