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. When not work eclipses work to such a degree, software developers start to think about changing careers.
Now, to ClearCase, a central monster in this nightmare of inefficiency. Here we have a very expensive and supposedly powerful software development tool. A giant in the industry. (For those who don't know, ClearCase is a version control system that allows concurrent checkouts and has all kinds of nifty and complicated features). I find that, as a developer, I typically spend about 30% of my time asking ClearCase to do something and then waiting for it to do what I asked. This is a tool that costs $100,000 per developer? Really?
There are many, many UI problems with ClearCase, and there's the fact that it is slow, but I think the esesential problem is one of concept. The whole stream and concurrent checkout model is, so far as I have experienced it, at best useless and at worst counter productive.
Now I know there are legions of fans of concurrent checkout VCS's out there who love their CVS and Subversion. But here is how I have observed my own behavior under a concurrent system vs. my behavior under a single-checkout system.
I am more timid, more afraid to make changes under the concurrent system.
How strange. Isn't the whole point of concurrent checkout to make teams work more efficiently because developer X doesn't need to wait for developer Y to check in a file?
Well, in theory, yeah. In practice, a little different.
The most dreaded situation in ClearCase (and I would guess, in other concurrent checkout tools) is the merge conflict, when that horrible multi diff window pops up. You've got to sort out what you changed with what developer Y changed and you've got to get it right. This happens at checkin time, or even worse, at "rebase" time. You are not in development mode. You don't have the whole problem in your head at that moment. You're just trying to complete your process. And your diff tool is unlikely to give you the sort of help that your IDE does. Still, you've got to resolve those changes or be damned.
Your best bet is to contact the other developer and go through the conflicts together. If you're lucky, you'll get it right. If not, untested, buggy code gets check into your VCS.
How is this better than single checkout?
The advantage of single checkout is you get easy to understand prompts about who is doing what. If you can see that developer X is working on file A, you can call or email and say, hey, let me know when you're done. Or maybe you can work on this issue while you've got that file.
Basically, the point here is that concurrent checkout is no substitute for good communication within your team. And relying on tools to deal with these kinds of situations instead of communication is probably not such a good idea.
Ok, I'm off in rant city here. Forgive me. But the point that I wanted to make about ClearCase is that monolithic tools like this have a purpose and it is not the one developers have in mind. The purpose of a tool like this is decided not by the tool's users, but by the tools purchaser, i.e., management.
Management's goal in spending all that money on ClearCase and the like is not to make developers work more efficiently. Quite the opposite. It is to force developers to do all of their not work, to prevent developers from thinking, from making changes, from writing code, in short, from doing work.