Relying on Uncontrollable Factors

Delivering projects on time matters more than perfecting every detail. An 80% quality project shipped on deadline beats a 100% project shipped late. Mistakes will happen and may cost 10 or 20 points, but the remaining 80% should come from experience and sound principles -- one of which is avoiding dependencies on things you can't control.

The Dilemma of Social Security Numbers

One example of the consequences of depending on uncontrollable elements is the use of national identifiers (ex. personnumers). While these numbers are key identifiers issued by the government, indiscriminate data collection was curbed by government policy in 2014. Removing critical identifiers is not the only challenge; it necessitates issuing new keys and altering existing designs. Over-reliance on uncontrollable aspects can lead to software that becomes unstable when faced with changes.

The Case of the "Discount" Function

Imagine a scenario where a function, "Discount," relies on the current timestamp. This creates a testing issue: running the test on Saturday would result in a failure, while Sunday would produce a successful outcome. Dependencies like this break tests unpredictably, and the fix is to transform such code into controlled, predictable functions.

Untangling Code and Testing

By extracting deeply embedded code into separate functions, we can create pure functions. A practical example of this is developing a "Discount" function solely for testing purposes, which helps us build functions independent of uncontrollable dependencies. When uncontrollable code causes issues, it makes clear why controlling your dependencies matters.

Single Responsibility Principle: The Path to Control

Through refactoring and adhering to the Single Responsibility Principle, we might end up with distinct functions with independent/domain-specifc tasks. While these functions seem to require external APIs for successful testing, we have the opportunity to create controlled functionality, allowing us to mock and test these interactions.

A Chain Reaction

One uncontrollable function can lead to a domino effect on the entire codebase, infecting all other functions that become dependent on it. Any function that depends on uncontrollable code becomes uncontrollable itself. Knowing the difference between controllable and uncontrollable elements -- external services, browser functions, system clocks -- is key to building robust software.

Source