Skip to content

Latest commit

 

History

History
65 lines (36 loc) · 3.07 KB

File metadata and controls

65 lines (36 loc) · 3.07 KB

Frequently Asked Questions

What problem is SHAM trying to solve?

SHAM addresses a visibility gap in software development. Many of the most important contributors to system health—prevention, risk reduction, and architectural restraint—produce few visible artifacts. SHAM provides a way to observe and discuss those effects over time.

Is SHAM a performance measurement system?

No. SHAM does not measure individual or team performance. It observes system behavior under change and is intended to support understanding, not evaluation.

Is SHAM meant to replace existing metrics?

No. SHAM is complementary. It can coexist with delivery metrics, reliability metrics, and operational reporting. Its focus is different: how safely systems evolve rather than how quickly work moves.

Does SHAM assume failure should be avoided entirely?

No. Failure is a normal part of system evolution. SHAM does not seek zero defects. It seeks to understand how much failure occurs relative to how much change, and how contained that failure is when it happens.

How accurate do SHAM measurements need to be?

Exact accuracy is not required. SHAM favors estimation and consistency over precision. The goal is to detect patterns and trends, not to calculate exact values.

Can SHAM be automated?

Parts of SHAM can be supported by automation, such as data collection and aggregation. Interpretation and decision-making should remain human-driven. SHAM is not designed to trigger automated actions.

How long does it take for SHAM to provide value?

SHAM is a long-view framework. Meaningful insights typically emerge over months as patterns accumulate. Early use should focus on calibration and learning rather than conclusions.

What kinds of systems does SHAM apply to?

SHAM is most useful for systems that:

  • Change regularly
  • Involve multiple dependencies
  • Accumulate technical and organizational complexity

It may provide limited value for static or trivial systems.

Can SHAM be used to compare teams or projects?

Direct comparison without shared context is discouraged. SHAM emphasizes interpretation within similar conditions. Cross-context comparisons often lead to misleading conclusions.

What if data is incomplete?

Incomplete data reduces resolution, not usefulness. SHAM assumes imperfect visibility and relies on consistent observation rather than comprehensive capture.

Is SHAM prescriptive?

No. SHAM does not prescribe processes, tools, or organizational structures. It provides a lens for understanding system behavior so informed decisions can be made.

Who should use SHAM?

SHAM is intended for:

  • Engineers and architects
  • Technical leadership
  • Teams responsible for system stability and evolution

It is most effective when used collaboratively by people with system ownership.

What is the intended outcome of using SHAM?

The intended outcome is clearer understanding. When patterns become visible, organizations can reduce unnecessary load, improve decision flow, and support healthier system evolution without relying on reactive intervention.

Understanding precedes action.