This question really contains two questions, which need to be addressed separately:
Why do some teams have a strict development process?
The simple answer is because if they don't, mistakes happen. Costly mistakes. This is true for development and it is true for the rest of the IT field as well (sysadmins, DBAs, etc.).
This is very hard for a lot of developers and IT workers to understand because most of us have only ever worked at one of the "extremes" - either big, Fortune-style companies with at least a dozen developers and strict processes to follow, or small, micro-ISVs or even freelance work where people just don't screw up badly, or the cost of a screw-up is low.
But if you've ever seen a company in between these phases - even a company with bright, talented IT staff - you'll understand the dangers of having no process or having a half-assed process. You see, communication among staff suffers from a Combinatorial Explosion problem; once you reach the level of around 6-10 developers on a single team, the primary cause of major or critical defects is not a lack of talent or know-how, but rather a lack of communication.
Alice asks around on Monday morning and decides it's OK to do reconstructive surgery in the trunk because nobody else is working on that part. Bob arrives an hour later, back from his vacation and full of energy and decides he's going to implement a new major feature in that exact same area, and why bother with a branch because nobody ever touches that code anyway? So Alice pays off that "technical debt", Bob implements his killer feature that's been on the back-burner for 6 months, and when they finally both check in their code (right before closing time on Friday, of course!), the entire team has to stay behind and try to work through the nightmarish hell of conflicts which continue to live on as bugs and regressions throughout the next couple of weeks.
Alice and Bob Both did a great job on the coding tasks, but they both started off with a bad decision ("what's the worst that could happen?"). The team lead or project manager takes them through a post-mortem, and hammers out a checklist to prevent this from happening again:
- Check-ins must be daily to minimize the impact of conflicts;
- Changes that will take significantly more than 1 day must be done on branches;
- All significant tasks (including non-feature work such as refactoring) must be properly tracked and assigned in the bug tracker.
I'll bet that, to a lot of us, this "process" just seems like common sense. It's old hat. But did you know that a lot of smaller teams don't do this? A two-man team might not even bother with source control at all. Who cares? It's honestly not necessary. The problems only start to happen when the team grows but the process doesn't.
Of course, process optimization is like performance optimization; it follows an inverse exponential curve. The checklist above may eliminate 80% of the defects, but after you implement it, you find that some other thing accounts for the remaining 80% of defects. In our fictitious-but-familiar example it might be build errors due to having different build environments, which is in turn due to the fact that there's no standard hardware and developers are using open-source libraries which get updated every 2 weeks.
So you have three choices: Either (a) standardize the hardware and severely restrict 3rd-party library usage, which is costly and may hurt productivity significantly, or (b) set up a build server, which requires cooperation from the sysadmin group and a full-time developer to maintain it, or (c) let developers do this themselves by distributing a standard virtual machine and telling the developers to build on that. Clearly (b) is the best long-term solution but (c) has a better short-term balance of reliability and expedience.
The cycle goes on and on. Every "policy" you see has generally been instituted to resolve a real problem. As Joel Spolsky wrote all the way back in 2000 (on a completely different topic mind you, but relevant nevertheless):
When you go into a restaurant and you see a sign that says "No Dogs Allowed," you might think that sign is purely proscriptive: Mr. Restaurant doesn't like dogs around, so when he built the restaurant he put up that sign.
If that was all that was going on, there would also be a "No Snakes" sign; after all, nobody likes snakes. And a "No Elephants" sign, because they break the chairs when they sit down.
The real reason that sign is there is historical: it is a historical marker that indicates that people used to try to bring their dogs into the restaurant.
It's the same in most (I won't say all) software teams: Policies such as "You need to add a test case for every bug fix" almost invariably indicate that the team has historically had problems with regressions. Regressions are another one of those problems that are most often due to communication breakdown rather than incompetence. As long as you understand the policy, you may be able to take legitimate shortcuts (e.g. I had to fix 6 small bugs but they were all in the same feature, so I can actually just write one test case for all 9 of them).
That explains why the processes are there, but it's not the whole story. The other half is:
Why is the process so hard to follow?
This is actually the simpler question to answer: It's because the team (or its management) is focused on repeatable results and minimizing defects (as above) but haven't given sufficient attention to optimization and automation of that process.
For example, in the original question, I see several problems:
The revision control system (CVS) is legacy by today's standards. For new projects, it has been superseded almost entirely by subversion (SVN), which itself is quickly becoming eclipsed by distributed systems such as Mercurial (Hg). Switching to Hg would make branching and merging far simpler, and even in my hypothetical example above, the daily commit requirement would become much less painful. The code doesn't even have to compile, because the repository is local; - in fact, the lazier developers could even automate this step if they wanted, setting up a logoff script to automatically commit changes to the local repository.
No time has been spent automating the Virtual Machine process. The entire process of obtaining, configuring, and downloading source/libraries to a virtual machine could be 100% automated. It could be an unattended process you run on a central server somewhere while you work on the bug fix on your local machine (and only use the VM to assure a clean build).
On the other hand, at a certain scale the VM-per-developer solution starts to get silly and you should just have a Continuous Integration server. That's where the real productivity benefits come in, because it (mostly) frees individual developers from having to worry about the builds at all. No need to worry about setting up clean virtual machines because the build server is always clean.
The wording of the question ("test case with all the steps") implies that there is some manual testing going on. This, again, may work for small teams with a relatively low work load, but makes no sense at all at a larger scale. Regression tests can and should be automated; there are no "steps", just a class or method added to the unit/integration test suite.
Needless to say, moving from Bugzilla to a newer (better) bug tracking system would make that part of the experience far less painful.
Companies aren't necessarily cheap or stupid just because they haven't solved these problems. All they know is that the current process works, and in some cases they are risk-averse and reluctant to change anything about it. But really they just need to be convinced of the benefits.
If developers spent a week tracking their time on all of the non-coding tasks, then you could easily add it up, show the management that (for example) a zero-capital, 100-man-hour investment in an upgrade to Mercurial would eliminate up to 10 man-hours per week on resolving merge conflicts, then that's a 10-week payoff and they'll almost certainly agree to it. Same idea with build servers (CI) or better bug tracking.
To recap: The teams haven't done these things yet because nobody has convinced the management that it is important enough to do today. So take the initiative and turn it into a cost-benefit equation; find out how much time is spent on tasks that could be simplified/automated with minimal risk, and calculate the break-even point and eventual payoff of a new tool or technique. If they still don't listen, then you already know what your remaining options are.
If developers spent a week tracking their time on all of the non-coding tasks, then you could easily add it up, show the management... and turn it into a cost-benefit equation etc...
Above part looks worth further expanding.
I can confirm that it works. Programmers used it few times in one of the projects I worked on and every time it led to desired changes.
My overall impression was that if done right, this trick can er overrule quite heavy amounts of management ignorance and inertia.
I would like to note though that company where we (developers) had to resort to this kind DIY approach was very immature IT-wise. At more seasoned software vendors I seen stuff like that mostly being done by managers themselves. And as a rule they were more productive at that than us programmers. Much more productive.
