Do you know what (Drupal) Technical Debt is? Of course you do!

Technical debt occurs when you take a shortcut, thinking "this will do for now. I'll sort it out properly later." And then you keep putting off "later", and probably forget about the issue ... until it comes back to bite you.

It's all those tiny things like a misspelled variable, whose misspelling has to be replicated evermore, or making a configuration change on a live site without capturing it in code, so that the live site is now different to the development one.

It's going [copy]-[paste] to a chunk of code when you really should be abstracting it into its own function.

It's neglecting coding standards. Even 'just this once', making your code harder to read and understand.

It's adding a <style> tag and a load of CSS into the header of a View rather than styling it properly in the theme, so that when someone comes along to make style changes later they are ambushed by mysterious styles coming in out of nowhere, and waste a lot of time trying to track down the CSS which exists in a database instead of a file (yes, it happens!).

It's (horror of all horrors) using the PHP filter to get yourself a value on a node or in a View or a block. This can cause particular havoc in the event of a PHP upgrade, if you've used a deprecated function.

It's not bothering to encapsulate your Javascript variables so you end up with global variables and namespace collision.

It's not using Drupal's theme functions because it's 'easier' to concatenate your HTML strings by hand so that you've got presentation in the module layer, HTML that cannot be overridden by themers and probably horrible spaghetti code.

It's writing SQL queries when you should be using the database abstraction layer because learning a new API is a real pain.

It's not thinking about the name of your new field for a couple of minutes before you type, because 'the machine name doesn't matter - nobody sees that, right?'

It's keeping all your code in a 10,000 line module, rather than splitting it out into thematic include files, or, even better, several functionally atomic modules. This is a battle we are waging with a site we inherited, and it's a right pain for a client to be spending money on us trying to figure out 10,000 lines of code, when well structured modules/includes files would have made life much easier, and saved the client money.

It's throwing logic into hook_init(), or a similarly regularly run function because it was quick and easy, when really you should be choosing more carefully to limit how often your code is called.

It's using .tpl.php templates as your first port of call, rather than your last resort, so that you end up in an ever increasing spiral of specificity and overrides in your presentation templates and nasty duplicated and redundant logic that could, and should, live in modules.

It's failing to comment your code so that when you come back to it a year later it seems opaque and obtuse.

It's basing the styling of a node on the node ID, rather than including a custom class so that if you replace that page with another you lose all the styling.

It's failing to keep your Features up to date so before you can make changes you need to grab a whole new database and update all the Features.

It's not using version control, such as git, so that deployments are difficult.

It's using version control but making mammoth commits with vague or misleading commit messages so that you lose many of the benefits of versioning.

It's not bothering to install Drush on your server because it's too much hassle, so then, in turn all your deployments are more hassle.

You get the idea. Do any of these sound familiar?

Each and every one of these examples happens, and none of them is a major, sackable offence. Well, possibly with the exception of the PHP filter. But each of them contributes to the overall technical debt on a project. You might be cutting corners in an effort to get a project in under budget, or you might be being lazy - the result is the same. Sooner or later today's choice will make tomorrow's task more difficult and expensive.

Mis-name that field at the outset of a project and you're dooming the project to a poorly named field, probably for its entire lifetime. If you don't fix the spelling of that variable name when you spot it, it will soon become out of the reach of find-and-replace and enter the realm of tedious debugging as you attempt to root out your legacy code.

Managers - concentrate on getting it done better, rather than quicker.
Developers - remember that you'll probably have to maintain this code, so it's best to keep your house in order.
Site owners - If your purchasing process is primarily a fiscal race to the bottom, then the trade-off is increased technical debt and added cost of maintenance and ongoing development.

Technical debt is unavoidable, because of pressures of time, budget, skill, manpower and many more, but it can be minimised.