The Matter of Version Pin Fear

The ticket was titled "Upgrade Node version."

It had been open for eight months.

Keerthi had added it to the backlog in January, when the security scan flagged that the project was running Node 12 and Node 12 had not been receiving security patches since mid-2023. This was a real concern. The ticket was legitimate.

In February, Keerthi moved it to the current sprint. In February's retrospective, it was noted that the ticket had not been completed due to capacity. It was moved to the next sprint.

In March, Keerthi began writing the upgrade plan. The upgrade plan required understanding what in the codebase assumed Node 12 behavior specifically. The audit took four hours and surfaced eleven dependencies, two of which had unresolved compatibility notes in their changelogs for Node 16 and above.

The ticket was moved back to the backlog.

By June, the pinned version had been there so long that upgrading had ceased to feel like a technical task and had started to feel like an archaeological intervention.

A new team member joined in July. The new team member asked, during onboarding, why the project was running Node 12.

Keerthi said: "It works."

This was accurate. This was also not the full answer. The full answer involved the two changelog notes, a CI step that had been patched around Node 12 behavior and was not documented, and the institutional knowledge that one specific API call behaved differently in Node 14 and nobody had had time to test whether that difference mattered.

The new team member nodded and did not ask again.

In August, a security scan produced the same report as January.

Keerthi reopened the ticket.

The ticket was moved to the next sprint.

Once the behavior is predictable, predictability counts as proof of success. The project ships. The version is pinned. Both facts are true. Only one of them will remain true indefinitely.