"Technical Debt"
===

[TOC]

Definitions of "technical debt":

## Needs

#### (in this doc)
##### HoloCentral
* To deal with inherited issues (from outside of HoloCentral)
* To deal with things forgotten/overlooked (unintentional or accidental)
##### External
* Clarity on deliverables and constraints

#### Also
* Single prioritized "source of truth" list of what we're working on including all features/bugs/chores/etc **OR** #% of time in sprint dedicated to working on technical debt tasks which could be in a separate tool (might be less visible to rest of org). Otherwise tech debt is unlikely to get worked on as it's outside of our usual flow.
* reasonable speed in dealing with things (vs long conversations)
* documentation of
* not only the solutions chosen but
* also the logic/thinking that went into it (reasons for decisions)
* a reasonable process of amendment and revision as we discover new needs

# HoloCentral

## Lack of clarity on the constraints for delivered software

- Unproven plans or architectural assumptions
- Unscorable work because of unclear operational requirements

One of our largest technical debt issues is that our organization as a whole lacks clarity on the operational requirements for delivered software that would objectively constrain our work, and help us focus on delivering things that can meet our operational requirements for each wave.

Operational requirements mean:

1. Projection of number of nodes that will connect per wave
2. Projection of level of performance that will be required for each wave for nodes, software components
3. A resolution of the level of infrastructure resources that will be needed to meet those requirements.

### Proposed ways to deal with lack of defined Holo operational requirements for each wave

1. Define operational requirements and make them transparent to the Holo Central team.
2. Use operation requirements for a wave to define the scope of work that should be done.
3. Recognize that some future operation requirements may need to be started earlier in order to be ready and achieved later. Afford and allocate people to work on these, instead of putting them off.

## Things forgotten/overlooked (unintentional or accidental)

- Refactoring code
- Security holes
- Supporting systems setup/maintaining
- Low Test Coverage
- Lack of Modularity
- Code Complexity
- Lack of the Documentation

> According to our definition of done, we should not introduce technical debt, but it happens.

Typically, the most important refactors are to fix critical issues that we are able to fix, while working on features. There could be hundreds of issues or tasks, and we should not have to spend hours discussing them all for what could be 10-30 minutes of work to achieve resolving.

### Proposed ways to deal with:

1. List of all discovered items ranked by concern level
- possibly sourced from multiple places: TODO lines, Github issues
3. Allot time in each sprint to just work on these issues
4. Anything that is a feature not yet implemented could go into pivotal tracker, anything that is a refactor of code could go into this github issue tracking on the project itself.

### Prevention techniques

1. We should write user stories in smaller chunks and spread out across more sprints
2. We should adapt user stories mid sprint where we need to, so that we can achieve our definition of done, and reduce scope

# External

## Inherited issues (planned or deliberate)

> eg. dependency APIs change

Inherited issues are issues that have a root cause outside of the software Holo Central is responsible for. Unfinished deps, problems that existed in code that our team inherits. Problems caused by half-measure approaches from previous implementations

### Proposed ways to deal with inherited issues:

These usually have a bigger impact on the company than just something that can be easily refactored

1. Therefore, these issues should be captured as user stories in our back log, and also should he identified as blocking for any relevant in process user story

2. We should also propose to take responsibility for a code base where it makes sense

3. And, our organization should encourage and support pull requests across teams if the PR is focusing on delivering our product