Read on Twitter
Software projects contain two types of complexity - essential complexity & accidental complexity.
The former is inherent to the problem being solved. The latter arises from the solution, from the tech used, etc.
Try to minimize accidental complexity, reduce magic, etc.
The former is inherent to the problem being solved. The latter arises from the solution, from the tech used, etc.
Try to minimize accidental complexity, reduce magic, etc.
There are many ways to do this.
First, don't over-engineer. Don't apply patterns without thinking if they're needed. Not every domain is going to benefit from DDD. Not every application will benefit from Microservices. Most don't need Kafka, don't need caching out the gate, etc.
First, don't over-engineer. Don't apply patterns without thinking if they're needed. Not every domain is going to benefit from DDD. Not every application will benefit from Microservices. Most don't need Kafka, don't need caching out the gate, etc.
Second, minimize magic inside the codebase.
Sprinkling decorators/annotations everywhere makes code harder to reason about. Concepts like dynamic proxies aren't easily understood, etc.
Simple solutions foster maintainability down the line, not needlessly complex ones.
Sprinkling decorators/annotations everywhere makes code harder to reason about. Concepts like dynamic proxies aren't easily understood, etc.
Simple solutions foster maintainability down the line, not needlessly complex ones.
On the same token as magic, I have another, albeit unpopular opinion - if time & resources allow, feel free to reinvent the wheel (sometimes).
Relying on third-party code introduces magic. Sometimes, a solution can be developed manually, & such will be more easily understood.
Relying on third-party code introduces magic. Sometimes, a solution can be developed manually, & such will be more easily understood.
Restrain from developing too much of an emotional attachment to your code. The code is a mere means to an end. In some environments, rapidly changing conditions imply rapid changes to sections of the code. That's okay.
Stick to known terminology. A factory is a factory. An adapter is an adapter. A proxy is a proxy. A test fixture is a test fixture.
Developers expect to see terms like this. Deviating from the standard can potentially cause confusion.
Developers expect to see terms like this. Deviating from the standard can potentially cause confusion.
On the notion of not having an attachment to your code, the same goes for technologies, and this is particularly pervasive.
You can have a "favorite" tech stack, but that doesn't mean it's best suited for the given situation. E.g. React Native perf vs. Xamarin perf.
You can have a "favorite" tech stack, but that doesn't mean it's best suited for the given situation. E.g. React Native perf vs. Xamarin perf.
This leads to a conversation on unconscious bias - just because the current trend of an industry is toward new tech X doesn't mean it's suitable for your situation.
You'll introduce complexity by trying to massage it to your use case when it wasn't designed to support it.
You'll introduce complexity by trying to massage it to your use case when it wasn't designed to support it.
