Preface
If you have picked up this book, you care about the architecture of the software you’re building. You want your software to not only fulfill the customer’s explicit requirements but also the hidden requirement of maintainability, and your own requirements concerning structure and aesthetics.
It’s hard to fulfill these requirements because software projects (or projects in general, for that matter) usually don’t go as planned. Managers draw deadlines all around the project team1, external partners build their APIs differently from what they had promised, and the software products we depend on don’t work as expected.
1 The word “deadline” presumably originates from the 19th century and described a line drawn around a prison or a camp of prisoners. A prisoner that crossed that line was shot. Think about this definition the next time someone “draws a deadline” around you... it will certainly open up new perspectives. See https://www.merriam-webster.com/words-at-play/your-deadline-wont-kill-you.
And then there is our own software architecture. It was so nice in the beginning. Everything was clear and beautiful. Then the deadlines pressed us into taking shortcuts. Now, the shortcuts are all that’s left of the architecture, and it takes longer and longer to deliver new features.
Our shortcut-driven architecture makes it hard to react to an API that had to be changed because an external partner screwed up. It seems easier to just send our project manager into battle with that partner to tell them to deliver the API we had agreed upon.
Now, we have given up all control over the situation. In all likelihood, one of the following things will happen:
- The project manager is not strong enough to win the battle against the external partner
- The external partner finds a loophole in the API specs, proving them right
- The external partner needs another <enter number here> months to fix the API
All of this leads to the same result – we have to change our code quickly because the deadline is looming.
We add another shortcut.
Instead of letting external factors govern the state of our software architecture, this book takes the stance of taking control ourselves. We gain this control by creating an architecture that makes the software soft, as in “flexible,” “extensible,” and “adaptable.” Such an architecture will make it easy to react to external factors and take a lot of pressure off our backs.