Relying on Uncontrollable Factors

In the fast-paced world of software engineering, there is a critical skill that stands above all others: the ability to consistently deliver projects on time, even when faced with urgency. Achieving an 80% quality project within the set deadlines is paramount. While mistakes are inevitable and may cost 10 or 20 points, the remaining 80% should be driven by our experience and principles.

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 serve as 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. Such dependencies on uncontrollable factors can become problematic, and it's essential 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. Discovering issues arising from the use of uncontrollable code can reveal the importance of maintaining control over our software.

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. Consequently, any function reliant on uncontrollable code will also become uncontrollable. Identifying the distinction between controllable and uncontrollable elements, such as external services or browser functions, is crucial for creating robust software.

Source