The term "soft" in "software" emphasizes code's intangible and adaptable qualities, allowing for easier adjustments to evolving needs than in other engineering disciplines. This flexibility ensures that last-minute modifications or errors typically have minimal effects on software development. Nonetheless, the code's non-physical nature complicates understanding and predicting outcomes. These difficulties arise from blind spots within or between abstraction layers, resulting in unforeseen problems or inconsistencies.
Practical software engineering centers around addressing this complexity and uncertainty. The essence of craftsmanship in software development is in the techniques employed throughout the analysis, design, construction, and maintenance stages. Mastering these techniques is essential for managing complexity and achieving success in software engineering. In a similar vein, Tom Kelly from IDEO, in "The Art of Innovation," compares the path to successful innovation to the careful refinement of a perfect golf swing:
"Back when I still attempted to play that challenging game, a golf instructor told me that there were just seventeen things to get right during the swing... They’re all simple. The hard part is putting all seventeen together in real time...”[1]
Similarly, software engineering success requires understanding fundamental principles that guide software design and development. Although these concepts are relatively straightforward, there's no silver bullet. The real challenge lies in effectively integrating these concepts, discerning when to adhere to them, and recognizing when deviating from the established rules is necessary.
This article marks the beginning of a series that explores programming lessons, navigating through the intricacies of coding principles, design patterns, and problem-solving strategies. My goal is to unravel the complexities of software development, providing insights and experiences to shed light on the art of crafting code.
What advice could enhance one's coding practices? Writing pure functions is one compelling answer. Pure functions are characterized by their deterministic nature and lack of side effects, meaning they consistently produce the same output for given inputs and function independently, without interacting with or modifying any external state or variables. Writing pure functions doesn't equate to creating good software. I am not implying that never writing impure functions is practical or never necessary. Instead, aiming for pure functions has beneficial ripple effects that facilitate the adoption of other effective programming strategies. Focusing on pure functions will result in code that is cleaner, more maintainable, and simpler to test.
Consider this impure function, total(double basePrice) :
public class Main {
static double taxRate = 0.18;
public static double total(double basePrice) {
return basePrice * (1 + taxRate);
}
public static void main(String[] args) {
System.out.println("Total Price: " + total(100.0)); // Total Price: 118.0
taxRate = 0.20;
System.out.println("Total Price: " + total(100.0)); // Total Price: 120.0
}
}This function is impure because it interacts with the external state, taxRate . total will not consistently produce the same output for given inputs since it depends on what the taxRate is set to. A mutation to the external state is required to change the tax rate used in the calculation. It is unclear to the person calling the function what the tax rate currently is or how to change it. It might be evident in this small example, but applying this pattern multiple times across a more significant project quickly becomes unmanageable.
This code is more challenging to maintain due to its reliance on the external state. It can make understanding the code difficult as the developer checks all the places where taxRate might be changed. It also encourages tighter coupling between the class functions, complicating future refactoring efforts. This function is less straightforward to test because the tester needs to consider the external states that are depended on or altered when the function is called. Additionally, in deployed applications, concurrent executions could modify the same taxRate , resulting in inconsistent values and further complicating testing efforts.
Now let's consider this function again, this time in its pure form:
public class Main {
public static double total(double baseAmount, double taxRate) {
return baseAmount * (1 + taxRate);
}
public static void main(String[] args) {
System.out.println("Total Price: " + total(100.0, 0.18)); // Total Price: 118.0
System.out.println("Total Price: " + total(100.0, 0.20)); // Total Price: 120.0
}
}By accepting taxRate as a second argument, the total function's dependencies are now explicitly defined in its method signature, clarifying the necessary inputs for developers. This change eliminates external state dependencies, ensuring consistent output for given inputs and simplifying how different taxRates can be applied. The immutable and explicit taxRate streamlines the maintenance of this function and any others that use taxRate . Testing is also simplified, requiring only the specification of inputs to verify the output without needing extra setup. Additionally, this modification makes the function safe to use concurrently.
Using pure functions leads to the concentration of complex integration code at the application's edges, where it's required. This strategy enhances code readability, facilitates better maintenance, and streamlines the testing of your application's core functionalities. Writing pure functions is just one of the many techniques to leverage for crafting better software. If you're using impure functions unnecessarily, incorporating pure functions into your repertoire is worthwhile.
[1]: Kelley, T. (n.d.). The Art of Innovation: Lessons in Creativity from IDEO, America’s Leading Design Firm. Crown Currency.