Change is inevitable during software development. So when developers receive feedback, they can either:
- Accommodate the request, or
- Pushback on the request.
The correct choice depends on three factors:
- What is the seniority of the parties involved?
- How familiar are they with the codebase?
- How much context do the developers have?
For junior developers, they may not have a solid grasp of how the application works and may lean on the suggestions of experienced developers. For senior developers, they should have a solid understanding of how the application functions and will insist on their approach if it’s well-thought-out.
What makes an approach good? If the approach meets the following:
- Acceptance criteria (requirements)
- Performance (scale)
- Quality (bug-free)
- Security
- Readability/maintainability (good design patterns and architecture)
- Testability
When can a developer pushback on a request for change? If it falls under the following categories:
- Nitpick (optional)
- Invalid/not applicable
- Bad practice (code smell)
So ultimately, knowing when to insist versus accepting a change depends on the value, context, and applicability of the feedback.