Too much version control and bug tracking overhead per change

issue-trackingsvnworkflows

I work at a place that is CVS-crazy and Bugzilla-nuts.

  1. There are so many branches off each release that one cannot count them. Everyone is constantly auto-merging.

  2. There is no fluidity at this job. Everything feels lock-step. It takes 25 steps even for a simple thing. It's not like being on a factory production line: it's like setting up a factory myself every day.

Example situation:

To fix a single bug, first I obtain a clean, new virtual machine. Then I create a branch for that single bug fix, based on another branch described in the Bugzilla report. I install the branch on the machine, set that up. I fix the bug. I check it in, leaving it and the machine for others to test with. Then I have to go into the bug control software and explain what I did and write a test case, with all the steps. Eventually someone else merges it with a release.

No matter how tiny the bug is, I have to do all of these things. Sometimes people combine work on multiple bugs, but as I said there are so many branches that this is hardly possible.

At any other job, I'd just go in and fix the bug. I barely even remember using SCM, although every job I've had has used it: that's because at every other job, they somehow kept it out of the way.

Is there a point at which the process gets in the way and becomes an end unto itself? Is that even engineering?

Best Answer

Is there a point at which the process gets in the way and becomes an end unto itself?

Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For upper management, it's frightening to even think that their business is in the hands of few geeks, and so the close their eyes from the reality and think of their dear "process" instead, which gives them the illusion of control.

That's why agile startups with a handful of good engineers can beat big, established corporations, whose workers spend 95 % of their energy on process and reporting. Some examples of once small startups that once did beat their competitors and/or created completely new markets:

  • Apple (Apple I was created by 1 engineer; there were 3 men at the company back then).
  • Google (created originally by 2 programmers).
  • Facebook (1-man effort originally).
  • Microsoft (2-man company in 1975).

One could easily say that these are just outliers, extreme exceptions, and to do something serious, you'd better be a big, established corporation. But the list goes on. And on. It's embarrassingly long. Almost every today-major corporation started as a garage shop, which did something unusual. Something weird. They were doing it wrong. Do you think they were doing it according to the process?

Related Topic