The term "technical debt" is nothing new in the software world, but it seems to be a standard practice with some rather large companies I come across these days.

Technical debt is the overhead that occurs when there’s decision to design or deploy the technology in this case (WSS- Windows SharePoint Services) - that expedient in the short term but increases complexity and is more costly in the long term.

For a single server to be the company intranet for a 1000 users, is pushing it a bit…but I’ve had this conversation twice with CXO’s in the past week, both who said , ‘Yeah, this is something we’ll look into when we go live!!!!’

What is Technical Debt? Two Basic Kinds

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior admin just takes short cuts. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, as the person didn’t know any better. . Sometimes, ironically, this debt can be created when a team stumbles in its efforts to apply a service pack inadvertently creates more debt. I call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this intranet done on time, there won't be another opportunity" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to move these two databases, so we'll leave them synchronized for now and reconcile them after the next service pack is released." Or "We have some web part written, with no documentation or instructions ; we'll clean that up later." Or "We didn't have time to test the alerts with the ISA server, so we won’t mention this functionality".

As a future blog post, I’ll mention how to avoid both types…. And the costs of these types.