Perfect is the Enemy of the Good - How My Architecture Crippled Development
updated about 1 year ago; latest suggestion about 1 year ago
Have you felt the pain of working in a code base that has no defined architecture?
We've all been there. Pass the spaghetti sauce, please! 🍝
But there's another side to it, too.
An over-designed architecture can cripple your development.
Design your app architecture to make development easy and straightforward. Designing for ease of use sometimes means forsaking technical sophistication, along with the complexity that comes with it.
In this talk, I'll share an example of a time that I laboriously crafted what I thought was the 💎 perfect 💎 architecture for my app. A monument to 'flawless' design. Except that it wasn't.
So, what happened?
Architectures like this can be too complex to use. That's what happened to mine. Other team members didn't want to follow the architecture. My brain was working overdrive trying to understand all of the complexity.
Everything follows the path of least resistance. Even a developer.
No language or framework is perfect, but the prevalent ones are (relatively) pleasant to use. Build your architecture around enabling future development. I advocate for less complexity and less implicit rules to keep in mind, while still providing the structure you need to keep things clean.
The goal of this talk
Let's discuss a healthier approach to architecture and software design.
I'd like to provide you with more real-world examples of architectures that are both correct and overly complicated (such as Swift's String object) and how to prevent it.
I'll share the reasons that overly-complex architectures cause issues for the development team, and how to ensure that your architecture serves your benefit.
I will invite you to consider ease of use when designing your architecture. Because an architecture you want to use is an architecture that will work.
Hi 4a0b4e68bfadfd7cf98b900651d625b771c5b51f. I've modified the final section a bit in order to clarify the purpose. Basically, the purpose is "How to approach architecture itself in a healthy way". :)
I have trouble with understanding the purpose.
Will this be a presentation about "What to do to prevent X problem in Y architecture" or "How to untangle my spaghetti?" or "How to approach Y architecture in a healthy way"?