Ask HN: To have (system) design sessions or not?
In my team, I suggest that before starting coding/implementing any middle-size/big feature (e.g., an HTTP endpoint that, supposedly, needs a new db table) the engineers involved (which usually involves all the backend engineers) should have a "design" session where:
- 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)
You could suggest a middle ground, like a design page where you request for feedback instead before implementation. Communication will be async, no meeting is required unless there is no consensus or details need to be clarified and rationale for final decision will be persistent somewhere for the future team to maintain this.
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.
IME no one will look at the design page or leave feedback, at least not after the first or second time a page is created. What will happen is the page will be used as a defense when the architecture is reviewed during code review ("I wrote about this two weeks ago and no one objected"). Eventually the pages will be abandoned.
Again, IME. Maybe better leads can force people to read and post feedback.
This is my experience as well, with the exception that design documents can be really helpful for onboarding new engineers quickly.
Yes, it should be "reviewed" and treated similar to a PR.
It is pointless to schedule meetings where the agenda will get derailed in the first 5 minutes and a dozen engineers/managers will end up having bike shedding debates. And your engineers are correct that such discussions always turn into popularity contests and junior voices end up getting drowned out.
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.
Agreed, sharing a tech spec / architecture decision record outlining the system design and it’s benefits and consequences with the team you’re seeking feedback from is quite effective.
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.
My opinion is to develop a culture of writing where people should spend solid time writing what they intend to do and why.
Don't let the majority win as that breeds shit. Build a culture of excellence and accountability.
If you're not the manager and don't have a strong voice in the team, it may not be reasonable to expect to be able to make changes in how the team operates.
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'm a big fan of having people discuss designs before implementation. That said, I'm not much more formal than nudging folks to have a discussion with their peers. It could be a meeting like you mention, or just an informal chat over coffee.
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.
Design reviews is one of the things I like most. You learn how to write, how to design systems, how to evaluate tradeoffs. You also get feedback from senior engineers. I will suggest that before having the meeting, the engineer should write a design document so your team can review it and discuss it in the meeting.
How about a design doc / tech spec before the meeting? The tech spec gets submitted for review, similar to a PR, then you can discuss it at the meeting. Otherwise I fear you'll waste a ton of time at those meetings and not get much out of it.
Perhaps it's possible to have the design meeting with a smaller set of invitees? Does everyone really contribute in the design sessions, or is it mostly people silently listening as a few dominant voices carry the meeting forward?
I'm curious about your industry - are you in a compliance heavy environment like automotive, aerospace, finance, etc? What are you working on? It matters - a simple CRUD app probably doesn't justify a design session: the problems are well known and understood and the solutions are usually straightforward to implement and to change.
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.