gistfile1.txt

**What is technical debt?** 
Credit card analogy
credit cards allows you to buy what you want now(shots at the bar, new iPhone, attendance at Turing)/you feel the pain later
technical debt is the same - companies get features/customers/revenue faster for less $ up front but comes with problems later

**Common Causes of technical debt**
Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes.
Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.
Lack of building loosely coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
Lack of test suite, which encourages quick and risky band-aids to fix bugs.
Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.
Lack of collaboration, where knowledge isn't shared around the organization and business efficiency suffers, or junior developers are not properly mentored
Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
Lack of knowledge, when the developer simply doesn't know how to write elegant code.

**Consequences of technical debt**
We frequently see this happen in startups. They continue to take on technical debt well past the time when it no longer makes sense. In the end, they spend all their time paying off their debt and no longer have time to improve their product.
Approaches to managing technical debt.
Static analysis tools are great, but entirely objective and relatively unintelligent. Code Climate will elucidate potential code smells, which then requires human intervention to determine the implications. Test are an immediate form of feedback. Usually, a smelly test translates to tightly coupled components, which is often the root cause of decreasing velocity. 
If a team is built from two individuals who (unintentionally) increase the amount of debt owed, this team is in need of at least one individual who will pay it down in tandem. Better, pair developers who have varying, but complementary styles. For each individual who's contributions tend to increase debt, consider pairing them with someone who values and doesn't mind paying down debt. Such a pair can immediately benefit the entire team, as discussions of debt, style and value will ensue regularly.

**When incurring technical debt may be advantageous**
By taking on a manageable amount of technical debt, you can get the added benefit of learning about a market, a feature, or even an implementation method without bearing the full cost of implementation. 
If nobody uses that feature, you can just throw away the code, debt and all. If instead, you eliminated all debt before launch, you would have wasted time and effort on improving dead code
When deciding to use technical debt we look at the above four variables. First, is there value to getting early feedback? If we’re building a feature we think users will value, we’re likely to consider taking on debt. If we know that it will be an important feature, than we get no value from the option to abandon our code. If we know a feature is valuable but there is uncertainty about the best implementation, we still might take on debt.

Resources
http://www.encodingbits.com/a-culture-of-credit
http://en.wikipedia.org/wiki/Technical_debt 
http://www.elevatedcode.com/2014/07/15/followup-to-technical-debt.html 

http://blog.codinghorror.com/paying-down-your-technical-debt/ 
http://www.construx.com/10x_Software_Development/Technical_Debt/