Grouping by Product vs. Grouping by People: The Importance of Organizing Software Development

The total value created by software is dependent on both the cost of creating and maintaining the software. Adopting a product organization approach can significantly increase the total value by reducing costs and decreasing the likelihood of premature death.

Organizing software development is crucial for efficient team collaboration and successful project management. GitHub is the quintessential example of grouping by product. By creating a repository, GitHub enables developers to consolidate all related project elements in one place, providing a streamlined experience for users looking to learn or contribute to a product on the platform.

Products can have a number of elements such as

• The source code
• An overview document, often in the form of a readme file
• Wiki including developer design documents and end user documentation
• Issue tracking
• Mailing list or group discussions
• Build, Test, & Release infrastructure
• Production settings such as DNS entries
• Production Monitoring
• Owners and permissions

An essential aspect of grouping by product is that each of these elements is specific and isolated to the project. For instance, when viewing issues, they are only related to that particular project and not to any other project. A litmus test for grouping by product would be if one could delete everything related to the project with one click without affecting anything else.

Some contrasting examples

A team creates an application called ImageResizer.

If someone wants to email the maintainers of this application they should send a message to the ImageResizer mailing list, not to the team mailing list.

If someone finds a issue in ImageResizer they should file a issue against ImageResizer, they should not create an issue and assign it to someone on the team.

What happens when organizing by people?

If one person owns ImageResizer and all the issues are assigned to them, what happens when that person leaves the company or no longer has time to maintain ImageResizer? If important design documents are stored in the shared drive of the person who created them and are not associated with a specific product, how will new hires find and access these documents?

When a company does not organize by product, each team is given the opportunity to create its own unique approach to software development, resulting in wasted time and resources as they reinvent ways to manage issues, provide documentation, etc. The unique ways they do this rarely if ever add value. This lack of standardization can lead to difficulties in onboarding and contributing, and can ultimately increase maintenance costs, decrease software longevity, and will result in complete rewrites. Teams will also waste time trying to standardize or creating product catalogs again and again. Other disciples such as managment and marketing will have a much weaker understanding of the software leading to less optimal outcomes.

In the worst case, a company may group everything around people rather than products. For example the issue system only contains teams that issues can be assigned to and not products that are owned by teams. Whenever there is a reorg in the best case the entire backlog is reassigned and in the worst case they are purged. Throughout the industry, team names frequently have nothing to do with products so even finding what team to assign an issue to can be difficult.

Overall organizing by people increases the odds that the software will not survive in the long term.

So use GitHub?

GitHub is simply an example where it forces grouping by product. When using a tool other than GitHub you will often be given the ability to compartmentalize the usage of that tool in any way you want. Despite this, it is important to prioritize organizing by product rather than by people for optimal efficiency and success in software development.

For example, a company that used GitHub used something else for their on call rotation. In the on call tool they organized by team (the default) and then added to teams different alerts from different products. It didn't take long for it to become a mess. Inverting it, organizing it around products that have alerts and then teams that are assigned to products fixed it.