Read on Twitter
One of the aspects most influential in my way of working is taking into account the different characteristics of costs in software (introduction/change/ownership). Back in 2015, @everzet presented a talk called "Min-Maxing Software Costs" at @LaraconEU:
Keeping this in mind when making decisions is essential when you want to keep velocity and want to maintain good expectations with your 
-holders. It allows you to built a strong relationship because trust is built when you deliver at expected points in time.
-holders. It allows you to built a strong relationship because trust is built when you deliver at expected points in time.
Techniques like hexagonal architecture (or ports and adapters) allow you to keep technical debt at bay and are a great concrete technique you can apply to lower cost of change by increasing the cost of introductions (slightly).
When we start a project, we have the least amount of knowledge/experience but we have to make many decisions. Later, we have all the experience, but we're stuck with some of the choices. This is why deferring decisions can yield incredible results.
The best way for me to do this is to focus on core domain needs first. If that's not possible/easy, find generic abstractions (like Flysystem) that allow you to defer decisions. Keep the focus on your use-case, not the implementation details, to guide your design decisions.
In uncharted territory, favor duplication over abstraction. Upfront design is more often wrong than right, recognizing this is the first step in combatting technical debt. Remember, duplication is far cheaper than using the wrong abstractions.
