Borrow the Environment, and Let It Argue Back

No Environment of Its Own

The workshop has no dependency manifest and no isolated environment. It runs inside the environment its host sibling already defines, borrowing whatever that backend has installed. For a repository, this is close to heresy — isolated environments are the first thing most projects create, and for good reasons.

The justification is that the workshop is a client of that backend. It calls that service on every run. Living in the same environment keeps the client and the thing it calls from drifting apart, and it means the libraries the workshop needs for image composition and network calls are already present because the backend needed them first.

The Rule With Teeth

What makes this more than laziness is the clause attached to it: if the workshop ever needs a package the host does not have, that is a signal to reconsider — not a reason to fork an environment.

Sit with what that does. A missing dependency is normally the most routine event in software; you add it and move on. Here it has been redefined as evidence. Wanting something the host lacks means the workshop is reaching outside the capability envelope its host defines, which usually means one of two things is happening: it is absorbing a concern that belongs to a sibling, or it is about to grow a capability the family already has somewhere else.

This is a general and underused technique. A constraint that would normally be pure friction gets converted into a detector, by deciding in advance what a violation means. The friction was going to exist either way; naming its meaning is what turns it into information.

Timing is what makes it work. The interpretation has to be written down before the event happens, because in the moment there is always a convenient reading available — you need the package, you are mid-task, and "this one is different" is the easiest sentence in engineering to believe about your own case. A rule written in advance is arguing with a version of you who had no deadline, which is exactly the version worth listening to.

Give your constraints an interpretation, not just a rule. "Do not add dependencies here" is a rule people route around. "Needing a new dependency here means the design has drifted, so stop and find out how" is a diagnostic — it tells the person who hit it what to do next, which is the only reason anyone obeys a constraint they could technically bypass.

Code

The same event, read two ways·text

EVENT: the tool needs a library the host environment lacks

ordinary reading                    this design's reading
----------------                    ---------------------
"add it to the manifest"            "why does this tool need that?"
30 seconds of work                  a design question, answered before code
resolved, forgotten                 -> is this concern really ours?
                                    -> does a sibling already own it?
                                    -> are we about to duplicate a capability?

# Same friction either way. Only one of them produces information.
# The trick is deciding the INTERPRETATION before the event occurs,
# because afterward the convenient reading always wins.

Exercise

Choose a constraint your team already enforces — a size limit, a dependency policy, a naming rule — and write one sentence defining what a violation is evidence of. Not the penalty; the diagnosis. Then check the last three times it was violated and see whether that diagnosis would have been correct. If it would not have been, the constraint is arbitrary and worth either rewriting or dropping.

Hint

A constraint that survives this exercise is one where violations cluster around a real underlying problem. A constraint where violations are scattered and unrelated is a rule inherited from somewhere else, and enforcing it costs attention that could be spent on a constraint that actually detects something.

No Environment of Its Own

The Rule With Teeth

Code

External links

Exercise

Progress

Comments 0