• Status: Proposed
• Deciders: Web and Mobile

Context

As an executive, in order to assess the ROI of Abyss, the Abyss Dashboard can display estimated hours a team has saved by using Abyss components vs. making their own. For this, the components need to have metrics that correlate with (but does not literally try to equate to) hours saved by a consuming team.

The measurement of internal complexity of a component or hook - its size, number of props or functionality - can be an initial estimate of the value it brings. Each component should have its complexity reviewed and assigned along the scale. Consider all value a component brings throughout the SDLC - testing, accessibility, etc.

Decision

• We will maintain TSDoc @complexity fields on components.
• We will score components' complexity along a Fibonacci scale - eg. 1, 2, 3, 5, 8, 13....

Alternatives Considered

For location/format

A shared Sharepoint document was what the initial estimates for Dashboard were stored in.

However, developers who maintain and add new components are best in the position to mark up the component's complexity right in the source coe.

For scoring

A T-Shirt size score was proposed, but Product wanted a separate scale to be distinct, and the scores would require numerical mapping.

Consequences

Any large changes to the scope of a component should require updating the complexity score.

Future Considerations

If the distribution of complexity numbers makes for unpredictable statistics, we'll have to consider adjusting the scale.