Written by Leo Gorodinski, CTO and Co-Founder at Alvys.
As a software development team grows, there’s a tendency for a ‘throw-it-over-the-fence’ model to emerge. This idea refers to a problem that can occur in software development when one team or person develops a piece of software and then “throws it over the fence” to another team or person to handle testing, deployment, or maintenance.
This mentality is unacceptable as a team grows. Roles become more specialized: the leadership team sets priorities, the project manager coordinates work across teams, the business analyst distills customer requirements into features specifications, the QA analyst runs tests, the UX designer focuses on the user workflow, and the engineer designs writes the code.
6 Best Practices of an Ethical Software Engineer
Properly managed, such a team can be greater than the sum of its parts. However, there is a danger of creating silos and a ‘throw-it-over-the-fence’ mentality. Here are some dysfunctions:
1. Involve the Right Teams
Product owners don’t involve the engineering or QA teams during ideation, discovery and prioritization. At first, things might move along a little quicker, but in the long run, this hurts the project by eliminating a point of clarification and a source of ideas, stifling visibility and compromising the sense of ownership.
At Alvys, we hold regular cross-department meetings to ensure all teams are up to speed. This allows us to respond quickly to customer requests for new modules and integrations in our transportation management software.
2. Give the Proper Product Specifications
Product teams create bottlenecks leaving engineers waiting for product specifications. If instead, product and engineers collaborates on the product spec, they can help each-other resolve contention and produce higher quality specs.
3. Look for Bugs as a Team
Engineers expect QA to catch all the bugs that they didn’t catch. On the contrary, quality should be the responsibility of the whole team, where QA plays a particular role, rather than being a crutch for the engineers. Engineering and QA should coordinate their testing plans and agree on areas of focus.
4. Ethical Engineers Proactively Monitor the System
Engineers don’t proactively monitor the system in production, relying solely on user reports or the support team to catch errors. However, involving engineers in production operations is the most effective way to fix underlying bugs. Engineers should be responsible for production operations and they should be empowered to fix things.
5. Be Transparent With Your Technical Initiatives
Engineers conceal their technical agenda from the product teams in fear of de-prioritization. Instead, engineers should be transparent with their technical initiatives, align them with the needs of the product, and seek support and feedback from the product team, building trust in the process.
6. Insist in on Quality Communication Across Departments
Management communicates exclusively with the product teams without addressing the other teams and recognizing their contributions. This certainly makes it easier for the leadership team, but over time, it can cause a disconnect.
This approach can lead to a lack of accountability and ownership, and can result in delays, bugs, and other issues. It is often considered an anti-pattern in software development and can lead to poor code quality, lack of documentation and poor communication between teams.
How to Avoid Throwing It Over the Fence
A better approach is to have a more integrated and collaborative development process where all teams or people involved in a project share responsibility for the success of the software.
In order to share responsibility for the project it’s best to foster a culture of open communication. Encourage team members to openly communicate with one another and to express their ideas, concerns, and feedback. This includes code reviews: Code reviews can help to ensure that the code is of high quality and that any issues or bugs are identified and addressed before the code is deployed.
Hold regular meetings before and after the code is deployed. Regular meetings between team members can help to ensure that everyone is on the same page and that any issues or blockers are identified and addressed in a timely manner.
Maintain Collective Ownership of Code
It’s important for teams to maintain collective ownership of code. As the size of the team grows, there is more room for error. If we rely on each other, communicate well, and take responsibility the errors can be minimized. The team can be greater than the sum of its parts.
Building complex software will always have challenges. To overcome these challenges, resist the temptation to create silos, define clear boundaries, and encourage cross-team collaboration and empathy.
Stay in touch with us for future blog posts (we will never share your information with anyone for any reason).