Now that we’ve seen what to tidy and how and when to tidy, we can discuss why to tidy. You don’t need to know exactly how a medication works to experience its effects, but knowing how it works gives you a deeper appreciation of it and allows you to use the medication in novel circumstances.
Theory doesn’t convince. No one is going to say, “Tidying is bullshit. Oh, wait, you’re creating optionality. I guess it’s a good idea after all.”
Understanding theory optimizes application. The forever questions in software design are:
When do I start making software design decisions?
When do I stop making software design decisions and get on with changing the behavior of the system?
How do I make the next decision?
These questions aren’t rationally, logically answerable because the information needed to find rational, logical answers doesn’t exist when we ask the questions.
Understanding theory sharpens your judgment for when you have to answer these questions on speculation. Understanding theory lets you disagree constructively with your fellow geeks.
Sometimes when I want to do X and you want to do Y, what we disagree about is simple. We are both trying to accomplish the same goal but in different ways. Theory helps when our disagreement runs deeper. When we are trying to accomplish different goals, this is when sharing a theoretical framework becomes valuable.
If we disagree in principle and we can discuss our principles, then we have a chance to agree on what to do sooner. We also have a chance to learn from each other. When we’re stuck on “X,” “No, Y,” then we’re stuck in a battle of wills, likely to be resolved through our relative power positions in our relationship.
This part of the book addresses the following questions:
What is software design?
How does software design drive the cost of software development and operation, and how does the cost of software development and operation drive software design?
What are the trade-offs between investing in the structure of software and not investing in the structure of software?
What principles, economic and human, can we use to inform whether and how to change the structure of software?
We started this whole journey by saying that “software design is an exercise in human relationships.” This book is primarily focused on your relationship with yourself: do you value yourself enough to make your work easier before you do the work? But this is only step one in the journey. In this section, we’ll consider one of the most persistent, complicated aspects of human relationships: money.