westurner

There are conceptual similarities and differences among
TDD, the Scientific Method, and Goal-Directed Organizational Planning.

How does Test-Driven-Development (TDD) relate to experimental
Hypotheses?

When practicing the Scientific Method (and keeping with Design of
Experiments), we’re supposed to start with a hypothesis,
experiment, and then test the hypothesis
before drawing a conclusion.

If the hypothesis is not met (in terms of statistical constraints,
boolean test pass/fail), then we reject the conclusion.

With Six Sigma DMAIC (Define, Measure, Analyze, Implement, Control),
in the Control step we re-evaluate whether the implemented approach
is achieving the intended objectives that we defined ahead-of-time.

“Validated Learning” emphasizes the need to control given changes
in predefined metrics, as well.

Control Theory and Systems Theory are all about how
changes in inputs (and feedback) affect measurable state
(outputs, systemic outcomes).

History, and various domains of science and policy, is chock-full of
examples of how attempts to Optimize (Minimize or Maximize) for certain
metrics have resulted in Unintended Consequences: where changes in
unmeasured variables are resultant from (or just “linked with”, in terms
of Confounding, Correlation and Causation) attempts to optimize. Can you
think of a few salient examples in your domains of knowledge?

There is math for solving multi-dimensional (“high-dimensional”)
optimization problems.

Most systems are inherently multi-dimensional: there are stocks and
flows (sort of like nodes with magnitude and uni-/bi-directional edges
with magnitude). A systems metaphor: a balloon animal filled with water.

We’d like to think that software is more discrete; that is,
software is describable in terms of how output results from changes in
input variables.

Formal methods of software design and analysis are often cost-prohibitive.
Practically, the problems we intend to solve with software are often
ill-specified: we don’t start with a complete functional specification,
we start with a vague idea of the problem we’d like to solve
(more efficient, more auditable, more logs) and work from there.
Agile development methods are designed to support teams of stakeholders
who are seeking continuous success in satisfying changing objectives.

So, then, there are two things to optimize (maximize) for
when attempting to deliver software which successfully achieves customer
expectations:

Functional Specification Coverage: whether all of the desired
behaviors are enumerated in at least one test.

Each Use Case and/or User Story should have at least one test.
(Behavior-Driven-Development tools make it easier to write
these tests with something like natural language;
so that developers/engineers can do what they do best).

User Stories can be written and rewritten from
the 5 W’s (Who, What, When, Where, Why)
to a Given-When-Then (and Why) pattern:

“Users can register for user accounts”

“As an unregistered user, when I complete the registration form,
and then click on the confirmation link sent to my email,
then I have a registered user account (obviously: in order to
onboard new users)”

Code Coverage: whether all of the actual code in the software is
covered by at least one test.

When some of the tests no longer pass, this is called “breaking the
build”. Teams working with Continuous Integration (CI) are aware
of this because all of the tests run for every change to the software.

When the build breaks, it is the whole team’s (and specifically,
the person whose changes broke the build’s) responsibility to
stop what they are doing and un-break the build (often by just
“backing out” the new changes (where they can remain in a separate
feature branch)) so that the whole team is not blocked.

Teams devise various ways to indicate that the build is broken
(CI emails, a build lamp, respectful verbal indications).

So, optimizing for Statement Coverage (when what we really want is
Branch Coverage) can be misleading: can lead to false confidence.

Branch Coverage and Statement Coverage are not independent
measurements: if there’s high Branch Coverage, there’s likely also
high Statement Coverage. Stated another way, change in Statement
Coverage can be predicted given change in Branch Coverage. Is this
confounding?

Note

Because Branch Coverage and Statement Coverage are notconditionally independent, there are a number of mathematical
analyses which are not appropriate (e.g. Bayesian inference).

It can be said, then, that Branch Coverage and Statement Coverage
are not independent components.

How does TDD relate to goal-driven organizational planning?

How do we know whether we’ve gotten there if we haven’t yet defined
where we need to be?

Organizations define criteria for success:

Mission

Goals

Objectives / Targets

Indicators / Metrics / Key Performance Indicators

In terms of Test-Driven-Development, many organizational “tests”
are not yet “passing” (“reasonability”, “realism”).

There’s an acronym for defining objectives: “SMART”.
There are various interpretations of each of the letters.
One such interpretation is “Specific, Measurable, Achievable, Relevant,
Time-Bound”. Here, we’ll assume that a Goal is more of a high-level
grouping for one or more objectives (though it could be argued that
really all we have are nested sets of Goals or nested sets of
Objectives):

Are we upholding the Organizational Mission?

Is this objective {S, M, A, R, and T}?

Is this objective Measurable?

Is this objective Achievable (Assignable)?

[…]

With tests for things in the future, we can define confidence intervals
(low, medium, high) as e.g. “pessimistic”, “realistic”, and “optimistic”.

Assuming the objective is to maximize,
given an interval,
there are then four possible boolean tests for success
(or just one, if we limit ourselves to TDD pass/fail):

Is the metric between the low and high thresholds?

Is the metric above the low threshold?

Is the metric within a defined threshold around the medium threshold?

Is the metric below the high threshold?

System Administrators sometimes define events for these types of
threshold intervals:

If utilization is below L, reduce the number of allocated servers.

If utilization is above H, increase the number of allocated servers.

Organizations sometimes define events for these types of threshold
intervals:

This weekend, I managed to get a fixed navigation bar configured
with the Bootstrap affix JS
and a fair amount of CSS iteration
for Sphinx (with the excellent sphinxjp.themes.basicstrap)
and have been merging the new styles into various
sets of docs that I’ve been working on:

[o] [UBY] show the currently #manually-selected link in the navbar
when the fixed navbar is scrolled beyond the viewport
(i.e. when showing the complete table of contents in the
full width sidebar navbar).

[x] Assert #anchor exists as a DOM element
with an id="anchor" property.

[o] Find and style each link to #anchor (href="#anchor"):

[X] mobile header navbar:

[X] UBY: Bold and add an arrow ⬅
next to the heading,
in place of the ¶ sphinx heading selector link.

[X] full width sidebar navbar:

[X] UBY: Bold and add an arrow ⬅
next to the heading,
in place of the ¶ sphinx heading selector link.

[X] UBY: If the full width sidebar navbar is on the screen;
and there’s a link in the table of contents
to the given #anchor;
and that link is not displayed,
scroll the sidebar navbar
so that the given navbar link is displayed
(with a few at the top, for context).

# on_rtd is whether we are on readthedocs.orgimportoson_rtd=os.environ.get('READTHEDOCS',None)=='True'ifnoton_rtd:# only import and set the theme if we're building docs locallyimportsphinx_rtd_themehtml_theme='sphinx_rtd_theme'html_theme_path=[sphinx_rtd_theme.get_html_theme_path()]# otherwise, readthedocs.org uses their theme by default, so no need to specify it

From casual inspection,
ReadTheDocs rtd_theme takes a different approach:

ReadTheDocs rtd_theme does support scrolling the left navbar
independently from the document;

ReadTheDocs rtd_theme scrolls the navbar and the document;

The ReadTheDocs rtd_theme navbar displays
a document-expanded
but otherwise collapsed
table of contents.

So I started to prepare a mega-tweet for our new substitute teacher, and started to reference a few links – because what good is an internet page without links – from my trusty ol’ redditlog, here: https://westurner.github.io/redditlog/.