Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:
- On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
- We don't need <insert pattern, product, or practice> its too <insert adjective>.
- Why don't you just <insert suggestion>.
- The code-base is in a bad state because <cite example>.
Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a "familiar" environment where he knows how to deliver value.
Here are the problems with this:
- Commentary rarely reflects a problem statement before offering a solution.
- Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
- Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
- Commentator may or may not have thought through the solution to the ultimate conclusion - to determine whether it is feasible, valuable, or reasonable within the context of the project.
I attribute these commentaries to each developer's on-boarding process, and their process of "mourning" the familiarity of their last engagement, while also trying to understand the current environment.
