I didn't know about this blog-post until today, but...
http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
It's a good read, so I suggest going there and reading it. And that's a reaction to another, longer post:
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
The tl;dr summation:
This applies to not just code writing, but even SysAdminly things. Something that starts as an occasional manual process (say, reindexing a database table when helpdesk call volumes get above a certain level), ends up being a daily one, then an hourly one. That's enough to motivate the most blunt of thinkers to just script up a way to index the database as a way to get more free hours in a day. Though the real fix is to put pressure on the application doing that to fix their index problem. IT is an ecosystem after all.
This also ties into IT politics right nicely as well. If most of the debt-servicing is being done by, say, the Sysadmin or helpdesk staff, then the need to pay it down in a determined way in order to reduce it may be hidden from the decision-makers who need to push that kind of thing. For self-built applications, debt-servicing requiring dev-time tends to be a lot more visible than helpdesk time. So having the various IT functions talk to each other is a very good thing when making a paying-down decision.
It's a nice way of putting it.
http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
It's a good read, so I suggest going there and reading it. And that's a reaction to another, longer post:
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
The tl;dr summation:
Any IT system develops Technical Debt. Things that require attention as a result of past decisions. For sysadminly stuff, systems that require hand-holding. As time progresses, the amount of technical debt being serviced can outweigh any new stuff being done. Possibly by quite a lot. Therefore, it pays to reduce technical debt in order to become more overall efficient.Or as Jeff put it, they had to put a hold on the StackOverflow new-feature development in order to service some of the debt incurred by earlier decisions. That liberated dev-time later on to make new stuff. For a dynamically growing site like StackOverflow, that's important.
This applies to not just code writing, but even SysAdminly things. Something that starts as an occasional manual process (say, reindexing a database table when helpdesk call volumes get above a certain level), ends up being a daily one, then an hourly one. That's enough to motivate the most blunt of thinkers to just script up a way to index the database as a way to get more free hours in a day. Though the real fix is to put pressure on the application doing that to fix their index problem. IT is an ecosystem after all.
This also ties into IT politics right nicely as well. If most of the debt-servicing is being done by, say, the Sysadmin or helpdesk staff, then the need to pay it down in a determined way in order to reduce it may be hidden from the decision-makers who need to push that kind of thing. For self-built applications, debt-servicing requiring dev-time tends to be a lot more visible than helpdesk time. So having the various IT functions talk to each other is a very good thing when making a paying-down decision.
It's a nice way of putting it.
Because I am surrounded by financially minded people who don't concern themselves with the details of technical projects, this concept is likely to be an extremely valuable communication tool in my world. Thanks for sharing.