3 ms·

What is frustrating about architecture to me is that it’s so rare to actually find a team with the discipline to care about it in code review. It’s easy to talk

by dcow 4y ago

What is frustrating about architecture to me is that it’s so rare to actually find a team with the discipline to care about it in code review. It’s easy to talk about it abstractly and whatever but when someone spent two weeks and throws a PR up on Thursday night expecting it to be merged the next day and they used the wrong design pattern, didn’t structure their domain model correctly or at all, and/or lacks clear interfaces, separation of concerns, etc. there’s no time for architecture and 99/100 times the PR gets merged. You know the story. And it’s not totally bad, albeit still frustrating. All the good architecture in the world doesn't matter if you can’t build a product that people want to use. Similar to design. I’ve been at a place once where people held others accountable to architectural concerns in PR. The reviews took longer and honestly it was exhausting at times but also probably one of the periods I developed most as an engineer if I look back at my career. All this leads me to the conclusion that there’s a time and place to entertain the finer details of code structure and system architecture. And it’s not when you don’t have a product. It’s only once you have a proven business that needs to be concerned with the scalability, understandability, ease of teaching others, modularization and ability to reuse, etc. that these things even start to become smelly. !Final note that a greenfield product must still be designed and engineered and build, but that’s not architecture. Architecture adds aesthetic qualities (that are ideally practical and functional as well) to a system.

Benjammer 4y ago
One way to solve that issue is to agree on the design pattern ahead of time before writing the code. Learning to think about the abstraction ahead of time is a powerful skill, but can be very uncomfortable to some people. There's a thing where we just allow people to say "I need to get my hands dirty, I can't effectively plan it ahead of time because I'll just end up changing my mind anyway," and nobody questions that reasoning or pushes back. The concept of "learning styles" has mostly been disproven. It's just a muscle you have to work, thinking about abstractions ahead of time without writing code. Writing helps a lot here. Anyway, if you're able to iterate on the design pattern before writing code, it can often only take a day or two, and then you don't have to spend another sprint re-writing the whole thing or whatever. Code reviews become a lot quicker/easier now as well, because you don't have to think about other design patterns while reviewing code, just the pattern already agreed on.

by dcow 4y ago

Benjammer 4y ago

One way to solve that issue is to agree on the design pattern ahead of time before writing the code. Learning to think about the abstraction ahead of time is a powerful skill, but can be very uncomfortable to some people. There's a thing where we just allow people to say "I need to get my hands dirty, I can't effectively plan it ahead of time because I'll just end up changing my mind anyway," and nobody questions that reasoning or pushes back. The concept of "learning styles" has mostly been disproven. It's just a muscle you have to work, thinking about abstractions ahead of time without writing code. Writing helps a lot here. Anyway, if you're able to iterate on the design pattern before writing code, it can often only take a day or two, and then you don't have to spend another sprint re-writing the whole thing or whatever. Code reviews become a lot quicker/easier now as well, because you don't have to think about other design patterns while reviewing code, just the pattern already agreed on.