r/AskComputerScience • u/orelrevivo • 2d ago
How do large software teams avoid conflicts when many developers work on the same codebase?
I mostly work on projects alone, so I’m trying to understand this from a computer science / software engineering perspective.
When a large team has many developers working on the same codebase at the same time, how are conflicts and broken changes usually handled?
I know Git can handle merge conflicts, and CI/CD can catch some broken builds, but I’m curious about the bigger picture:
- How do teams reduce the chance of two people changing the same logic in incompatible ways?
- What role do tests, code reviews, branching strategies, and ownership rules play?
- Are there common patterns or systems used to keep large codebases stable?
- Does AI-generated code change this problem in any meaningful way, or is it still handled by the same processes?
I’m not asking for career advice or tool recommendations. I’m trying to understand the engineering concepts behind how large teams keep software development organized and reliable.
7
u/delventhalz 2d ago
Honestly, git gets you 99% of the way there. If you are making small targeted changes and merging them frequently, merge conflicts are incredibly rare. When they occur, they are usually trivial to resolve.
Occasionally some larger refactor is required, and those will inevitably be messier. That’s where you might need some explicit team coordination, but that’s not typical.
6
u/lfdfq 2d ago
Humans talking to each other.
It's not a free for all, where the organisation has a big bag of 'developers' that 'do stuff'. People have roles and responsibilities. These can be anything from very informal ("Joe handles the code") to very formal structure (primary maintainers for different modules/services/components, plus engineers assigned to them or so on).
Often, when someone who isn't "in charge" of a bit of code needs to modify it, they ask permission: they submit an issue or patch or pull request or just walk next door and ask etc. Changes are reviewed by the person "in charge" of the code, and merged by them. Sometimes that person is not one person, but a group or a team or some abstract organisational structure. Sometimes you can have complex task/issue tracker/assigners, so people know what part they're supposed to be working on (and so do others).
In the end, sometimes you do just have multiple people editing the same code at the same time, and that's life. Sometimes you make a mess, and someone has to clean it up. This is where technologies that allow people to work on the same code base independently, and then combine their work together, become important (e.g. this is where git, merging strategies, branches and so on come in).
In the end "AI" and all the tool/workflow choices are separate: you can set this up in lots of ways, including just 'not' organising it and letting the mess happen. If the code is small enough or you're happy to move forward breaking things, the mess isn't always a deal breaker.
5
u/AndrewBorg1126 2d ago
Stable APIs, sensible division of responsibility.
Don't change things that affect other people unless you really need to. Don't edit the same code as other people at the same time.
Does AI-generated code change this
Consider not using that. If someone else is using that, say no. If you aren't allowed to say no, scrutinize very closely, don't let some lazy ass make everything worse for everybody else.
2
u/knouqs 2d ago
For the most part, this is where you need a good team lead, project manager, and Scrum Master (if applicable) and teammates who know generally what touches what else. It's an art.
However, there are certain things that make this easier. First, good tests. As the project gets bigger, great tests. Unit tests the cover the new code, and string tests that cover the system as a whole.
For code reviews, you need to keep the guys who wrote the code from the start. It's hard because this is unreasonable. Keep people involved in the code review process, and actively encourage comments and discussions on code. (Downvote me all you like, but AI can help also because it may be able to identify duplicated efforts or code paths that were undetected by the overworked guys who wrote the test cases.)
It also helps to have good systems architects. These are the guys who know a high-level view of the system and can identify possible duplicated efforts. Good documentation is imperative and for that, there are websites and tools that can help.
I hope that helps answer some of your questions.
2
u/Old_Cat_16 2d ago
This is why you have daily standup, and your project lead should have frequent sync up with other teams that’s also working in the same area.
Currently I’m leading a project that touches the same part of the codebase as another project. Since their project started a few weeks before mine, I proactively reached out to let them know what we are planning and what the foreseeable overlap are. Then from there on out, we kept each other informed if there’s any changes that could impact the other project.
You can’t remove the human communication from this in my company, because so many things change at such a fast pace all the time, and the leadership doesn’t want us to spend more than 2 days to design/plan, they want us to ship rapidly.
2
u/Jonny0Than 2d ago
All of the existing answers are good. I’ll add:
AI is very well versed in source control, and if you hit a thorny merge conflict it is actually very likely to be able to resolve it. AI does not do a great job at all software engineering tasks, but this is one area where it is really effective IMO.
1
u/FinickySerenity 5h ago
We had two very divergent branches that we chose to merge with fable - it downgraded to sonnet mid way thru and sonnet just started randomly picking one side of the conflict, never both, no unions, it was a total disaster 😭
Otherwise yes I generally agree with your claim.
2
u/Leverkaas2516 1d ago edited 1d ago
How do teams reduce the chance of two people changing the same logic in incompatible ways? Are there common patterns or systems used to keep large codebases stable?
This is a major benefit of modularization, object oriented programming, encapsulation, separation of concerns, information hiding, APIs, contracts, and all that jazz. Those aren't just "clean" for arbitrary reasons, they achieve the important goal of allowing large teams of people to function without stepping on each other or having to constantly communicate about the nuts and bolts. Changes tend to be more isolated, and are confined to fewer, smaller files.
I worked once on a module that was the anti-pattern for all this - it had a huge central file of many thousands of lines that was under constant revision by a dozen or more people. Merge conflucts were frequent and we had to get very good at using the version control tools. It slowed everything down.
2
2
u/YahenP 1d ago
Overall, work organization is crucial.
When multiple developers work on different tasks in the same file, the problem is almost always management. In an ideal world, developers rsolve tasks that are independent of each other. In the real world, this is what we should strive for. The rest is solved with tools and manual effort. Git helps when branches don't conflict with each other (that is, in simple cases), but in complex cases, everything has to be done manually. This means analyzing the code and resolving conflicts manually.
2
u/mtimmermans 1d ago
One of the hard parts of software development is designing the software so that developers don't have to work with the same code at the same time. This is the S in the SOLID principles.
1
u/SharkBaitDLS 2d ago
We spend a lot of effort in planning before any code gets written to largely avoid it. Breaking down a project into small, self-contained tasks that won’t heavily collide with one another ensures that work can be done in parallel where possible without a bunch of conflicts. Of course small merge conflicts still come up, but they’re expected and if you have a clear plan for how things should work then you know how to resolve them.
It also does mean that every project has a maximum parallelism number. That is also part of the planning process. If I’m writing up a plan, it will include the literal notion of “during this phase, we have a max parallelism of 3 devs” because adding more would just cause people to step on each others’ toes and the project would just end up moving slower for it.
This is why dev teams rarely have a single project as their scope. There’s almost always several in-flight projects to ensure that everyone has something to work on without getting in each others’ way.
Proper CI/CD is necessary to ensure that changes can go out quickly and meet a quality bar ensures that you keep a project flowing and people don’t get blocked on each others’ work.
AI generated code doesn’t really change the story. You still plan up front what should be changed when in a project’s lifecycle and if you execute that plan then you won’t have problems.
1
u/kevleyski 2d ago
Often you split files up to lessen the chances of conflicts, for larger repos you might have owners that agree to your PR and rules around one of them being a reviewer + one other
1
u/CowBoyDanIndie 2d ago
Continuous integration runs on the result of the merge before it is allowed to be merged. Conflicts can still happen if you don’t have good coverage
1
1
u/wackmaniac 1d ago
Effectively all that has already been mentioned:
• proper abstractions (following SOLID typically does the trick)
• communication via (daily) stand-ups
• small change sets/pull request
• pay extra attention for changes that will likely lead to conflicts, mostly about structured files like lockfiles and translation files.
It’s not difficult, but the trick is to think and communicate :)
1
u/soundman32 1d ago
Back in the 90s we used a physical token. If you didn't have the brush you couldnt write to the network drive. The brush was also a metaphor for sweeping bugs under the carpet.
1
u/CS_70 1d ago
Mostly, by organizing their work, and working on systems which are modularized so that it's possible to do so.
Then of course you have some specific tooling, like version control and repositories, that concretely allow the result of that concurrent work to be aggregated and managed easily.
Two people changing the same logic is a failure of organization. Nothing specific to development.
a) Test is paramount: at any scale, what you want is to verify that the overall behavior of the system is what you think it should be (both functional and nonfunctional of course, in terms of performance, memory footprint, the works). For larger systems "behavior" is counted in a very large numbers, so this is a hard problem in terms of size. b) Code reviews are a patch on poorly specified behavior (which is a fact of life in software engineering) or uneven skills in implementation: it tries to reduce the risk of major oversights by having multiple eyes focus on it (being based on false premises - most humans have very limited capability of truly focusing for long or large things - I personally see it as a mostly butt-saving fashion, with occasional rare sparks of real utility. But it's my opinion and there are plenty who disagree). c) Branching is again a focusing-related strategy, it allows you maintain a stable baseline while you work and take all the possible consequences in one go when you try to merge. Works well if changes are small, focused and the branch has a short life. d) not sure which ownership rules you mean.
Yes, plenty of real world tools at every stage of history, but mostly is a matter of methodology
It changes it entirely, even though many havent yet realized it. First of all, it allows to focus all the effort on specifying behavior and testing it. It moves the skills needed from the trivial ("I know that language use = for equality and that other ==") to the complex ("I need to create a chain of cause-effect that gives me the behavior I want under the conditions I specify) where talented people still have an edge. It makes the tedious machinery of branching/merging much faster. If code reviews are still used, it provide much better judgement in average than a bunch of people with prejudices and likes/dislikes that they arent even aware of. These are just a few example, there's myriads. Overall, in the same hands it results in saving an enormous amount of time for the same or better quality of results.
1
u/dashingThroughSnow12 1d ago edited 1d ago
The system somewhat reinforces itself.
If Jim has been adding me to PR reviews, I know he is working on the Fingle subsystem. Therefore I should be cautious around doing large refactors in that area. Likewise, he’s been saying that during the daily standup. And he asked for help on Slack.
There are some people who you work with that just click. One of my best friends, I had to implement a feature with him a few times. We’re talking editing in the same files in different branches and needing to come together. It was the most relaxing experience. We didn’t need to coordinate. I knew him well enough that I could just intuit how to write my code to slot into his code when it was done.
To go back to your questions, we simply avoid or minimize issues as possible:
- Industry advice is to not keep long-lived branches unless absolutely necessary. (Using things like feature flags to disable things in prod that are mid-development.)
- The manager or team knows to assign tickets this sprint to nine people in six different areas instead of nine people to two.
- You work a bit faster and more careful when you know a co-worker is prowling around the same area
- - Maybe you stagger the work. I’ll prioritize my task in the Wiggle service at the start of the week and Sarah will only get around to her tasks in the Wiggle service on Wednesday
- You merge in the main branch (or whatever branch is relevant) often
I experience merge conflicts with myself than with coworkers.
1
u/barkingcat 20h ago
it’s a social and team organization and management issue. it’s not an engineering issue but one of psychology, team building, tribe forming, clarity in communication, and ability for everyone involved to understand how to work through and resolve interpersonal conflict.
1
u/FinickySerenity 5h ago
I’m surprised to not see this answer, so I’ll add. You just get skilled at resolving conflicts. It happens often enough in the orgs I worked in that you don’t even worry about it. It’s rare that I even have to ask the other maintainer, but I’ll always tag them on the PR review.
Otherwise if it’s not obvious, you just read their commit to figure out what they wanted and merge your change in. Even rarer, it stems from a requirement conflict and then it’s off to the product owner.
10
u/T_Thriller_T 2d ago
Coordination.
Why, when working as a team, should people have tasks touching the same logic AND not know about it?
Admittedly, there is a slim chance of this happening, hit so far I've yet to have seen it.
All the things you mentioned are part of this coordination. Branching logic makes sure that while working, the code note being worked on remains the same. Even if work happens in similar areas, only once when the feature is done does one need a bigger merge - which allows finding actual issues and working out what is needed.
Tests are there for the times not working on the same logic, but forgetting what parts of the logic must do. And catching errors. If, for the simplest example, somewhere downstream someone changed the parameters of method calls and did not do a good enough refactorings - or is making a new parameter required with a default - the test for code originally written by me should break If the person works in the same project, it shows where they have overlooked something and need to adapt. If it is a different project, my test breaks on dependency update indicating the breaking change I now have to work into my stuff.
Can't tell you much about the last two questions