- potential high-level solutions are discussed
- potential implementations are discussed (not low-level details, but at least the important/risky ones)
- and once a "final" decision is made, whoever is in charge of pushing the feature live to production can start with the implementation. The rest of the team can review the implmentation later on knowing that it should follow the final decision the team agreed on
The team doesn't like the approach that much because:
- it takes time ("Omg, yet another meeting?")
- "review of the design can be done at PR code review time"
- developers should have more freedom when it comes to designing systems ("we don't want to be just code monkeys that implement the design of others")
I disagree with these reasons (but nevertheless comply with what the majority says). Mainly: having design sessions takes time, yes, but it pays off (in my opinion we are actually saving "implementation/review" time). Second: PR reviews shouldn't be for discussing architectural/design decisions (by the time the author has submitted a PR, it's already too late to make any significant changes. And if any significant change needs to be made, then we are losing tons of time as stated before). Third: design sessions are for everyone to speak up and suggest potential solutions, so we are not just "code monkeys", we implement the designs we agree on.
I'm probably the second most senior engineer in the team but I'm not the "tech lead". I do feel certain kind of responsibility in suggesting improvements in the way we work, but ultimately I don't have such a strong voice in the team, and we just do what the majority decides. The engineer manager knows about it, and while they agree we want to improve the way we work, they suggest that it will take time until we reach that point.
Just wanted to know your opinion about it. I'm a very relaxed person: while I do like to make suggestions to improve things, I don't mind if my suggestions are not ultimately taken into account (I wonder, though, if I would end up burned out of this kind of situation if it keeps happening repeatedly)
In any case your reasoning is 100% right, perhaps you can sell it to the team with examples of past implementations which were:
- buggy, and the team had to alter them in later iterations
- slow, because there was no design beforehand and devs were stuck for some time trying to figure out what to do
- inconsistent hence you create some mess and potentially tech debt (one dev is using A to solve an issue while another uses B).
It’s the tech lead’s/architect’s/em’s job anyway to identify those and improve the team’s output, keep raising this to them and use specific examples and experiences. If there aren’t any, perhaps there isn’t much value to push for this.
Again, IME. Maybe better leads can force people to read and post feedback.
A better approach is to appoint a single tech lead, give them the freedom to make technical decisions, have them write a RFC/tech spec, and have others review the spec (by commenting on it and asking questions). Once there is consensus on the major items then development can proceed.
Not only does this remove another meeting from the calendar, but it also allows everyone to contribute asynchronously and requires explicit buy-in from each requested reviewer.
Don't let the majority win as that breeds shit. Build a culture of excellence and accountability.
Most companies of a certain size and technical complexity end up settling on circulating a document outlining the design and soliciting feedback, rather than setting up meetings. I agree that PR's are too late for design feedback. You could try the document approach for features you implement, and see if people respond and it makes your work easier. If that works, perhaps others will pick it up too?
I've seen too much harm come from overly prescriptive approaches to design review, which I've seen lead to people resisting, and that might be going on with your team too.
However, let's assume for a moment that you have these meetings regularly, that everyone fully engages, and that the meetings don't get sidetracked: what problem are you trying to solve? Just that you have a spec to use during implementation? That you get a say in how things are built? That you don't paint yourself into a corner architecturally?
Counterpoints:
1. An implementation spec might not be that useful. If the person working on the task understands it thoroughly, it might be more work to spec out the task and communicate the impact/rationale to others than it would be to just do the thing. Additionally, given that business requirements will change, your spec document will no longer be useful in the future (it will be an outdated specification for a system that solves a problem that no longer exists). If you want a spec for your own purposes, write one. You could even go so far as to solicit feedback on it before you start writing code. Personally, I find that writing this kind of detailed spec up front takes the joy out of programming. "All of the problems are already solved and now I just have to translate prose into code" does not make for a very fulfilling career.
2. If you want a say in how things are built, talk to people. I suggest doing it through the lens of helpfulness (e.g. "I know a lot about this component that you're changing, there are lots of sharp edges and moving pieces, and I'd like to help you navigate them if you're open to it"). A spec is not the only way to accomplish collaboration.
3. If you don't want to paint yourself into a corner architecturally, get the team to agree on longer term, big picture technical/architectural goals. You (presumably) hire skilled engineers. Build a shared vision for the thing you're working on and let the skilled people on your team carry the system toward that goal. You don't have to be personally involved with every architectural decision.
Personally, I only find design sessions useful when talking about the big picture: tell me about the system as a whole and how it interacts with other external systems. Anything more granular than that, my eyes start to glaze over and I rapidly lose interest. Discussing a hypothetical software system in depth is not something that I find productive. Give me an IDE and some code to read and I'll build a much better understanding of what needs to happen than a meeting will ever give me.
All of that said: if you work in automotive, aerospace, or other compliance-heavy industries, design sessions that involve a compliance SME are a must. You don't need to get so granular as to start specifying classes and stuff like that, but establishing clear requirements that must be met to remain in compliance is just something you have to do. Not doing so is professional negligence. Design sessions are useful here because the compliance requirements (generally) change much slower than typical business requirements.