My team recently started requiring an implementation proposal on the issue that has to be approved by their peers. It saves a lot of wasted effort by exploring the problem domain collaboratively before development begins.
I’ve seen people suggest this and then the horror on other engineers faces that follows. In my opinion, the difference between a good eng/dev and a great one is that they recognize when the effort is too big to chew in one bite, too unknown to reason about clearly without a plan, and/or too many gotchas already exist in the codebase to make it easy.
The great developers I’ve known would pull back and think about the problem longer, draft up some plans and noodle on it with colleagues and I love that foresight.
The problem with a policy like this is that you’re slowing everything down for the sake of the few that might need it. Your team leads should be able to determine which ones should require the investigation and keep the team moving efficiently.
It shouldn't be slowing good developers down, it should just be changing the order they were already doing things. One of the most fundamental ideas I took away from my Software Engineering course in college was that catching errors early in the development process is more efficient than catching them later. It is a lot faster to grind out ideas in the planning phase than to churn during code review, because the development and code review processes are a lot slower than just replying to comments.
More importantly, when experienced developers formalize their reasoning for a proposal, less experienced developers can learn from it. That same knowledge becomes archived in a format that is easy to discover and consume in the future.
