You are just not understanding how the developement works at all...
No it is not.
Yes, it is.
If that is true, bugs will be less rampant because there will be a specific person assigned to those tasks.
That's why QA teams are paid thousands to break the programs and find outputs that aren't supposed to happen. And even then, it's quite easy to let errors slip, sometimes basic stuff every programmer learns at school.
What is 100% certain is they are incrementally adding features or modifying/changing/removing features so it is very easy to say that they have some sort of tabulated list which they cross-out when its done.
I didn't say the contrary. I was explaining that software development is based on assigning the tasks. You have a list of features that need to be done by a certain date. So you assign each one to a person or a small team to do them. You don't put your whole team programming on the same thing, because there's no need. Unless you want to enter merging code hell.
Small development teams are more congruent. TOS likely just have a 10 or less people doing everything so tasks gets shifted around, some priority ones done by everyone and some minor ones done by a few.
If you put your whole team programming the same thing, you are wasting resources and, again, entering merge hell. Usually you go for either one person working on a single task alone or a two people group where one codes and the other helps with the thinking process. If it's something big and urgent, they will probably go through a planning together and divide it in small tasks that each person can do.
Small development teams are more congruent
Believe me, even having just two people working in the same file can be a nightmare.
Software is prone to bugs? Only rushed developers do that.
Hahahaha, no, not really. Software is made by humans and humans make mistakes, big ones or silly ones, it's always happening. That's why we usually go through code reviews with our colleagues or our seniors, QA... That's why software testing is a really huge business, sometimes the team that tests the software doesn't even belong to the company making it and is actually hired from a different professional testing company.
Even the agile method mention you keep mentioning has debugging before release.
Debugging happens only when something goes wrong. The "release", like you keep calling it, goes through a testing process. The testers report any anomalies they find. Developers then enter the debugging phase to find the bugs that produced those anomalies and fix them.
Of course, as you write the code, you will also write tests for the different components (unit tests) and for the relationships between the components (integration tests). The testing of how the whole program works and if it does what is expected is basically done "after release" (this release being a runnable version of the program, like our Alpha Tests, Closed Beta Tests...).
Softwares will always have minor bugs but for game-breaking bugs to push through release, there are so many to conclude here like only having a really small development team, being rushed and so many else.
Of course the ideal is for the software to not have any major bug, but that can't really be predicted. But again, that's what the closed beta tests were for, to find bugs. If they didn't take care of the bugs during the closed beta, they will do so during these next weeks/months until the next CBT or OBT.
And you are forgetting the fact that I mention every company/people have different design processes.
I believe I answered to that already.
People weren't even supposed to access the hair panel during our CBT. It was already there for some time now. During the beta, bugs were found and fixed, even though it did take a few days to fix some of them. I don't even understand what the problem is here...?