---
title: Six parallel workstreams, one integration bill
description: Six workstreams that passed in isolation created ten integration defects.
  The cost of parallel work depends on the rules, state, and artifacts they share.
url: https://sxnlabs.com/en/opinion/2026/08/05/parallelisme-la-facture-arrive-a-l-integration/
lang: en
date: '2026-08-05T09:00:00+02:00'
tags:
- Method
- Project
- Integration
- AI
---

# Six parallel workstreams, one integration bill

Six feature workstreams passed their tests and reviews, then produced ten serious defects when they came together. They had been designed as independent even though they changed the same quotes, job sites, and contacts, enforced the same business rules, and rewrote some of the same files.

The application schedules field visits, sends quotes for signature, and notifies clients by text message. Parallel work shortened each workstream's development time while the effort required to produce a coherent product remained.

<figure class="schema">
  <picture>
    <source media="(max-width: 640px)" srcset="/images/posts/parallelisme-integration/convergence-mobile.en.svg?v=20260827-layering" width="375" height="564" />
    <img width="940" height="494" src="/images/posts/parallelisme-integration/convergence.en.svg?v=20260827-layering" alt="Six workstreams that passed separately converge in pairs on the same objects, business rules, and artifacts, then on an integration that reveals ten serious defects." />
  </picture>
  <figcaption>The tickets separated the work, but not the systems being changed.</figcaption>
</figure>

## Two correct workstreams, one inconsistent flow

One workstream added online quote acceptance: the system checked the quote, confirmed the order, and generated the invoice. Another let the back office change the job site or delete the associated request. Each behavior made sense in isolation and had test coverage.

Together, they opened a gap between validation and confirmation because the back office could change the job site while the client was signing. The client then approved the current quote while the signature provider still held a contract describing the previous version.

No isolated test covered that sequence. The defect lived in the seam, around shared state that could change before the irreversible action.

## The tickets hid a shared system

- **A duplicated business rule.** Three paths needed to preserve a quote's recipient, using three definitions: a full contact fingerprint, only its ID, or no check.
- **State read too early.** Two requests could load the same draft and generate separate PDFs, with no reliable way to determine which one represented the accepted offer.
- **A shared artifact.** Two branches rewrote the database schema. The merge removed a table required for appointments even though each branch was correct in isolation.

## Faster implementation moves the bottleneck

When every workstream can interact with every other one, the maximum number of pairs to examine follows `n × (n - 1) / 2`:

| Parallel workstreams | Calculation | Possible pairs |
| --- | --- | ---: |
| 6 | `6 × 5 / 2` | 15 |
| 10 | `10 × 9 / 2` | 45 |

These 15 or 45 pairs do not imply as many conflicts. They are an upper bound; actual integration cost depends on the density of the dependency graph and the cost of each seam.

AI lets one developer start several workstreams cheaply. Generation, local tests, and review parallelize well. Reconciling two interpretations of a business rule remains sequential work that requires an understanding of the whole product.

## Before starting parallel work

<figure class="schema">
  <picture>
    <source media="(max-width: 640px)" srcset="/images/posts/parallelisme-integration/stack-devis-signature-read-write-mobile.en.svg" width="375" height="810" />
    <img width="940" height="544" src="/images/posts/parallelisme-integration/stack-devis-signature-read-write.en.svg" alt="The back office changes the job site that the signature flow reads. This dependency requires coordination and an end-to-end test; the PRs are stacked only when the second depends on code from the first." />
  </picture>
  <figcaption>The read/write overlap requires coordination, not necessarily a stack. The second PR branches from the first only when it depends on its code or schema.</figcaption>
</figure>

1. **Map reads and writes.** List the objects each workstream reads or changes, along with shared invariants and artifacts.
2. **Classify dependencies.** If one workstream writes data that another reads or writes, or if they share an invariant or artifact, plan their integration together.
3. **Stack code dependencies.** If a PR uses code or schema from the previous PR, base it on the previous PR's branch so its diff remains focused. Merge the stack from the bottom upward and restack its descendants after each change. A business dependency alone needs coordinated integration and an end-to-end test, not necessarily a stack.
4. **Close race conditions.** Bind the signature to an immutable version of the quote and job site, then compare that version in the same transaction that confirms the order. If it differs, invalidate the signature and regenerate the contract.
5. **Test after every merge.** Regenerate shared artifacts, then rerun the affected business flows. A green suite on each PR does not cover their seams.
6. **Schedule integration.** Name the integrator, set the cadence, and reserve the required time. The delivery date must include this work.