In spite of many engineers choosing to view the above as an organizational failing, we all know what could have been done differently: rather than go heads down on the feature, the engineer could have sought to collaborate with his / her peers. The pull request issues could have been identified through a design review, and the usability issues through a UX review. Both reviews could have occurred before any investment in writing code, and may have taken no more than a couple hours of additional project time. In large companies, this minimum process would be enforced through a Software Development Lifecycle (SDLC) - but in smaller organizations, the collaboration is delegated to individual engineer. But instead of seeking collaboration, the engineer chose to make decisions on his own, and to communicate these decisions to his teammates through a pull request.
The lack of collaboration and information sharing is one of the single greatest contributors to engineering inefficiency in software development today. There are a number of common causes - e.g. lack of experience, personal insecurity, mistaken belief collaboration is inefficient, need for control, etc... - but all collectively contribute to lost time and effort.
Here are some of the benefits you get by being collaborative and open with your work:
- Better decisions - By opening decisions up to feedback from a group, you will improve the quality of your work product.
- Team buy in - By being open and collaborative, you also foster buy-in from your team on the key decisions you make in a project.
- Eliminate knowledge silos - Your teammates will be able to better support the software you build when you freely share information and solicit feedback on key decisions.
- Non-linear thinking - By engaging a diverse team in decisions, you will sometimes find new and unexpected solutions to problems you thought you fully understood.
- Learning environment - By engaging the full team in key decisions / reviews, you enable engineers of all levels of experience to learn and advance their skills - including you.
So next time you start a new software project, take a moment to consider how you can engage the broader team in key decisions. Doing so will ensure you deliver the best possible work in the least amount of time, and do so with the least amount of frustration.