Work is defined in the most basic sense as labor directed toward a useful purpose. Labor, thus, is any sort of toil involving physical or mental exertion. Breakin' rocks in the hot sun is labor but not work. Laying out a patio is labor and work.
Should we distinguish work from fun? I think not. Work, at its best, is truly rewarding and satisfying and even fun. Gardening on the weekends might be a hobby, but it is still work. In my twisted protestant-work-ethic saddled mind, the most truly fun endeavors are also work.
Life is work. What else is there? Watching television? If you're not struggling to accomplish something, whether it's raising a houseful of kids, building a dog house, or constructing the perfect diff algorithm, well, then, what's the point? Sure, hanging back with a beer and a few friends is good living, but is it really possible to enjoy that kind of relaxation if you haven't earned it, in your own mind at least, with a hard day's or night's work?
Maybe it's me . . . But I'm drifting off topic here.
Our jobs, as software developers, are made up of work and not work. The work is the good stuff--writing software, designing architecture, even doing maintenance code. The not work is what kills us. Going through elaborate processes. Attending long meetings. Filling out timesheets (yes, this can be labor in itself). Dealing with issue tracking software and other bureaucratic headaches.
Often the not work is necessary and important, if unproductive. When it takes up a reasonable amount of our time and allows us to spend 90% of our days on the work, well it's not so bad and resentments are few. But as projects grow and management gets more "serious" the not work grows as well, and then life at "work" (well for me anyway) grows wearying.
Currently, the project I'm working on requires me to participate in my client's process and software development methodology. This process is rather top heavy with not work. Every single code change requires a number of administrative steps to accomplish. I find that I spend perhaps 40% of my time on not work tasks.
Until last week, that is.
At that point our project entered the QA cycle and a whole new array of administrative overhead was introduced. In order to make a very simple code change to, say, fix a configuration file, here are the steps required:
0) If an issue does not exist in the issues tracking software, create one.
1) Check out the code from ClearCase (more on that monster in a moment). This step is fair enough.
2) Make the change.
3) Build the code with the new change (a process that generally takes about 5 to 7 minutes)
4) Verify with other developers that it is OK to deploy your build to the development server, there being no way to test locally.
5) Deploy your build (a process that takes about 5 minutes)
6) Test. Fair enough here.
7) Check in your changes. (Again, fair enough.)
8) Contact an administrative person to request that the stream be unlocked so your changes can be delivered.
9) If you had to create your own issue, contact an administrative person about setting your issue to "Open" status so that you can modify it.
10) Mark the issue as "needs peer review"
11) Find someone to peer review your changes. (A catch 22 here. This step is supposed to happen before changes are delivered, but no one can see your changes until they are delivered. Nice.)
12) Deliver your changes in ClearCase.
13) Go into the continuous build system and fire off a build (A process that takes 5 to 7 minutes)
14) Mark the issue as Fixed, being sure to include all of the details of what exactly you changed.
15) Hooray, you're done!
Accomplishing all 15 steps can typically take up to 2 days or even more, when the actual work part of the process takes maybe 30 to 45 minutes.
About the Author:
For further information on software outsourcing, offshore outsourcing and offshore software development, please visit http://www.a1technology.com which is a leading Software Development Company.
Source: www.isnare.com
