What is the most efficient and effective way to ensure software code quality in a team of 50+ developers?

Home - Quora Link

The only really effective way to get it done is through proper architecture. You get your strongest and smartest devs, put them in a room together, take away all their day-to-day concerns and have them only work on architecture. If they’re coding, it’s only on the most mission critical parts.

These are the people that are best able to make decisions that will save the company millions of dollars. But they can’t do it if they’re not positioned to.

These guys need to be accountable only to the CTO of the company. They will set the direction of the very structure of the entire technical apparatus of your enterprise. They will figure out ways to break up the company’s concerns so that 50+ developers don’t have to all work together.

Because honestly speaking, 50 devs is way too big for a single team. Amazon has a rule, called the two-pizza rule. Teams need to be no larger than it takes to feed them with two pizzas. They don’t adhere to this religiously, but it’s a good guide to technical organization.

You’re asking about code quality. It took me finally working in a real team of developers (I’m used to being a lone wolf) to realize that code quality is a red herring. The business makes the same amount of money whether it’s bad code or good code that’s running it. If the code is bad, but still accomplishes its objectives, then there’s no point in fixing it until new features come along the pipe that require fixing it.

I’m the biggest code quality nut there is, and yet many times I’ve found myself choosing not to improve bad code even when I see it and know how to fix it. If new feature needs me to, I’ll fix it, by then I’ll have plenty of insight on what it takes to fix it. But my default stance is towards spending more time understanding problems before sticking my big apey hands in there to fix them.

Code quality only really matters in two situations. 1) when the application is so well-integrated with each other that bad code in one piece really does affect other pieces. Example: Adobe Photoshop. It’s one application where everything really does have to work together seamlessly. The rest of the situations fall into category 2) the application is poorly architected and so requires more developers to work together in more ways than is necessary.

Developers work best when they can completely “own” their domain. If they have to get 6 sign-offs to make every little change, then that encourages them to not be self reliant and rather to constantly be asking for assistance. Poor architecture means that concerns are not sufficiently isolated enough for each dev to feel like they have their little piece of ownership.

If your company has 50 developers on a single team, they need architects to figure out how to split them into ten teams. 5 developers is plenty for one team.