Canonical page: https://tellenze.com/blog/keep-dependencies-from-becoming-surprises # Keep Dependencies from Becoming Surprises ![Two museum staff examine a teal audio cable beside headphones on an exhibit pedestal.](https://tellenze.com/blog/keep-dependencies-from-becoming-surprises/cover/01m4fpkh09343peh8w5xvzpbsg) Two teams agree on Monday. A small audio-guide example shows why they may need to test their shared assumptions on Thursday. At a fictional museum, Amara is building an audio player for visitors. Her sample data has English and Portuguese recordings for every exhibit. The language buttons work, the recordings play, and the screen looks ready. Leo's team is preparing the catalogue that will supply the real recording links. The two teams have agreed that the export will arrive on Monday. When Amara tries an early export, one exhibit has only an English track. The player still offers Portuguese. A visitor choosing it gets an error. Leo isn't waiting for that recording. The exhibit is meant to have English audio only. His export is correct according to his team's understanding; Amara's player is correct according to hers. They have a delivery date. They haven't yet agreed on the thing crossing between them. ## Let the receiving team try something small It would be easy to turn this into a request for more complete documentation. Sometimes that is needed. Here, two carefully chosen exhibits would tell the teams more than another general paragraph about the catalogue. One exhibit has both recordings. The other has English only. Amara tries them through the part of the player that builds the language choices. That small sample brings a product question into view. Should Portuguese disappear from this exhibit's options? Should it remain visible with an explanation? Should the player offer English instead? A file format cannot make that choice for the museum. For this illustration, the team decides that a visitor should see which recordings actually exist and choose among them. The player mustn't silently switch the visitor's language. Leo's export will identify the available tracks, and Amara's player will use those tracks to build its options. Now “sample ready” has a useful meaning: Amara can run both exhibits through the player and inspect the agreed language behavior. A file attached to a ticket is only the beginning of that check. The sample needn't contain the museum's entire collection. It needs enough reality to challenge the assumption that every exhibit behaves like the first one. ## Protect the agreement you actually need [Ian Robinson's 2006 article on consumer-driven contracts](https://martinfowler.com/articles/consumerDrivenContracts.html) develops the idea that a provider benefits from knowing which expectations its consumers rely on. It also makes the limitation clear: exposing those expectations doesn't necessarily remove the coupling between them. For the museum teams, the important expectation is modest. An exhibit has a stable identifier and a list of available recordings, each with a language and a usable location. The player doesn't need to depend on the catalogue team's internal publishing workflow or the order in which editors add recordings. The teams can choose how to protect that agreement. With a small file export, representative examples and focused checks may be enough. With independently evolving services, automated contract checks may earn their maintenance cost. [Pact's introduction to contract testing](https://docs.pact.io/) describes checking messages against agreed expectations, with verification on both the consumer and provider sides. A mock used only by Amara's team cannot establish that Leo's application will produce the same messages. Even a verified message contract has a boundary. [Pact's guidance on when to use it](https://docs.pact.io/getting_started/what_is_pact_good_for) explicitly separates contract testing from the provider's functional tests and from performance testing. In this example, checking the catalogue response doesn't prove that the recording link loads, the audio is intelligible, or the language control works for someone using assistive technology. Those need their own checks. And no test can recover a meaning that the teams never agreed to express. A useful contract lets both teams change details safely within a shared expectation. It should be small enough that they can explain what would break it. ## Monday may be too late for Thursday's decision Leo may reasonably need until Monday to export the whole collection. Amara may need the two-exhibit sample by Thursday to settle how the player handles availability. Those dates describe different needs. Putting only Monday in the plan hides the earlier one. In the fictional team's dependency note, Leo owns the sample and Amara owns trying it in the player. They agree on the two cases, the expected visitor behavior and the Thursday check. The note links the sample and the result once they exist. They also agree what happens if the sample slips. Amara can continue independent work on layout and playback controls, but the language behavior remains unverified. At Thursday's check, the teams decide whether to make a safe representative sample together, narrow the trial, or change its date. A handmade sample can help them settle meaning. It still doesn't prove that the eventual catalogue export meets the agreement. That check remains visible. This makes a delay discussable. Leo can explain whether the missing part is the data, the agreed shape or the ability to produce it. Amara can say which decision is waiting and what she has already checked. “Catalogue still in progress” would leave them guessing about all of that. ## Some dependencies deserve less coordination There is a danger in becoming good at managing handoffs: a team can build an elaborate routine around a dependency it ought to simplify. [Team Topologies' explanation of team interaction modes](https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies) distinguishes purposeful, temporary collaboration from consuming a service with clear ownership. It offers a useful direction for the museum teams. Work closely while discovering the boundary; make ordinary use easier once it settles. They may need a short shared session to decide what an absent recording means. They shouldn't necessarily need another meeting every time a curator adds an exhibit. If every player change requires the catalogue team to invent a new export, the sample has uncovered a larger question. Perhaps the interface is too specific. Perhaps the publishing and player responsibilities are divided in a way that makes routine changes awkward. Another status meeting won't answer that. The appropriate response depends on the work. A temporary exhibition can justify a simple, manually checked file. A guide that changes every week may need a dependable publishing interface and a clear way to evolve it. Neither situation automatically calls for a microservice or a new testing platform. Before the next cross-team delivery, try four questions together: - What will the receiving team do with this input? - Which ordinary variation is missing from our example? - When do we need to test that understanding, ahead of the final delivery? - If that check can't happen, which decision will we make about the waiting work? Keep the answers beside the work, in whatever shared tools you already use. For Amara and Leo, the most useful early delivery is a slightly inconvenient exhibit: the one without Portuguese audio. It gives them something concrete to work out while Monday is still in the future. ## Further reading - [Consumer-Driven Contracts: A Service Evolution Pattern — Ian Robinson](https://martinfowler.com/articles/consumerDrivenContracts.html) — consumer expectations, service evolution and the coupling that remains. - [Introduction — Pact Foundation](https://docs.pact.io/) — how message contracts connect consumer expectations with provider verification. - [When to use Pact — Pact Foundation](https://docs.pact.io/getting_started/what_is_pact_good_for) — where contract tests help and what they don't establish. - [Team Interaction Modeling with Team Topologies — Team Topologies](https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies) — different reasons for teams to work together, and how those interactions can evolve.