Invest in Design for Long-Term Sustainability
The Design Stamina Hypothesis is a concept that uses a chart to demonstrate the amount of work a team can accomplish without engaging in design work versus the amount they can achieve while including it. Investing in design work early on in a project can be beneficial in understanding the purpose of your application. However, it is difficult to determine the inflection point at which design work becomes necessary, as it varies from project to project. Teams often need to weigh the potential impact of future changes before deciding whether to focus on finishing tasks or on design work. The Design Stamina Hypothesis must consider when to prioritize design work in the project timeline.
It’s important to remember that every programmer is a designer, whether or not they know it. Every change made to a system implies changes to the Design. The experience level of the programmer is less relevant than the structural changes they make to the application. Design is an ongoing process that occurs with every line of code written. The critical question is not whether programmers are doing design work but whether they will regret their design choices later. Therefore, every new change should move the system towards a more straightforward design.
Consider the cost as a quality measure for goal orientation. Each picture should be explored, and related ideas should be combined into a cohesive theme. Visualize the vertical axis as representing cumulative functionality, while the horizontal axis represents time. Each change to an abstract interface corresponds to a shift in its concrete implementations. Actual deployments sometimes require modifications to the interfaces they rely on. The volatility of an object in a system depends on its dependencies. If an element is expected to be volatile, it should be independent of difficult-to-change features. Abstractions are less volatile because other objects depend on them.
Difficult-to-change applications are rarely enjoyable to work on. Object-Oriented Design is about managing dependencies to handle change. It emphasizes flexibility over perfection. The hallmark of a confident designer is their tolerance for ambiguity in an object’s class.
Loosely coupled objects promote independent context between components. They must know more about the environment or dependencies. Objects define the role that different implementations can play. Loosely coupled classes are not tightly bound, allowing for substitution across roles. An object should only know what it needs to work to be reusable. If I understand my API and see the API, I can plug and play objects anywhere they are loosely coupled. They are context-independent and can be used throughout the system. We can create object-oriented systems by adhering to loosely coupled, cohesive, context-independent APIs.
