Why almost every ‘Temporary’ Workaround is Permanent (Chapter 8)

Somewhere around the fourth month of most projects, a team member will inevitably utter a variation of the same phrase: "Just hardcode it for now; we'll fix it after the release." While some may argue that shortcuts are sometimes necessary, the real issue lies in the fact that "temporary" doesn't have an owner, ticket, or deadline of its own. It remains in place until someone forgets that it was ever meant to be temporary in the first place, at which point it becomes a critical component of the system.

To better illustrate this point, consider a real-world scenario: a team needed to ingest pricing updates from an upstream provider within three days. The fastest path was to inject a direct HTTP call into the business-logic service method responsible for handling the data. By parsing the JSON inline, manually mapping a few fields, and moving on, the team managed to meet the deadline and ship the feature on time.

However, success often breeds invisibility. Two months later, the upstream team decided to switch to Kafka, rendering the initial HTTP call obsolete. The now-unused call semantics were embedded within the domain-facing method signature, necessitating a complete redesign of the service method. Three weeks later, the platform encountered another challenge: edge devices in the field could no longer maintain a reliable Kafka connection, forcing a switch to MQTT instead.

This resulted in the third and final rewrite of the same core logic within five months, with each iteration impacting more code than the previous one, as more components had grown dependent on the leaked transport assumptions.

The core issue wasn't the choice of REST for the first solution; it was the fact that the shortcut welded an evolving decision into stable logic. This failure could have been avoided if the system had a defined interface that encapsulated the domain's question without being tied to a specific transport mechanism. By building this interface, any changes to the underlying transport would only require modifications to the bridge-impl, leaving the business logic untouched.

However, this boundary was absent during the initial shortcut, leading to a series of three transport migrations in just five months - each rewrite costing three weeks of development time and requiring extensive debugging to identify and resolve the quietly growing dependencies on the leaked implementation details.

Ultimately, the lessons learned from this experience emphasize the importance of establishing clear boundaries between business logic and transport mechanisms from the outset. By ensuring that there is only one place where the conversion from database shape to domain shape occurs, teams can prevent the downstream costs of deferred decisions.

While shortcuts may seem like a quick solution in the short term, they often lead to significant downstream challenges that can be avoided by investing the time upfront to create well-defined interfaces and adapters.