Management Objectives & Coder Objectives

Technical Debt.
Management has business goals - both short term and long term. The two need to be balanced. That is the art of management. Excessive focus on one, or the other, will lead to failure. The short term, by its very nature grabs attention; in most cases to the detriment of the long term. In software development this leads to the taking on of Technical Debt.

Consequences.
As Technical Debt piles up the code becomes increasingly fragile. Fixing one defect introduces other defects. Feature addition becomes a nightmare. Customers become increasingly dissatisfied. The brand erodes.

Causes.
Technical Debt 101 explains the factors that cause technical debt. I strongly recommend reading the article.

Concentrating on today's fires is exciting. Trouble is, the excitement is paid for by taking on technical debt. In this, management have very "willing allies" - the Coders. What are a coder's objectives? The most important are:

1. Improve job market prospects. Hence acquire skills, knowledge.
2. Ensure that they are not easily replaceable by their current employer. The higher the technical debt the greater the job security.

Practices required to prevent buildup of technical debt do not figure in the objectives of most coders. In the rare case that it does, management, by their actions, ensure that it is soon given up.

Software Exorcism is a book that deals with Technical Debt. The book, as it's title says, is about getting rid of the "evil spirits" that can take up residence in software. An evil spirit, in Hindustani, is called Bhoot. Once evil spirits take up residence the software becomes what, in Hindustani, is called a Bhoot Bangla - a Haunted House. Now there is a vested interest in not exorcising the evil spirits.

Exorcism: First Step.
Technical Debt must be managed. Managing anything - whether diabetes, or sports teams, or whatever - requires metrics. Managing financial debt requires financial metrics. Managing technical debt requires technical debt metrics. Managing technical debt will ensure a development process that,

1. Prevents unhealthy build up of Technical Debt. 
2. Takes corrective action to reduce it to defined acceptable levels.

Malleability

Malleability is that property of a material that allows it to be easily shaped. Gold is malleable. Stone is not.

Code should be malleable.

Polymorphism (from the Greek poly meaning "many", and morphe meaning "form, shape") adds to malleability. So do unit tests. Coupling destroys malleability. Cohesion enhances it.

Reluctance to modify code is a sure sign that malleability is being degraded. Attend to it. If it is hard to do now, it is not going to easier on its own.

Code that is not malleable become "Bhoot Banglas". Code that is not malleable is code that is petrified (from the Greek petro for stone). Petrified code leads to petrified code maintainers.