How Rational Clear Case Stole my Innocence and Nearly Ruined my Life

A Simpler Time

When I was in college in the late 90’s, we didn’t use source control. The concept existed but wasn’t pervasive in my environment. (Or, if it was, I have no recollection of using it). And, why use it? We were working projects lasting less than a semester (usually far less) and in teams of 3 or fewer for the most part. We also generally telnet-ed into servers and stored most of our source there since most students had windows machines and most of our assignments required *NIX, meaning that the “backup/persistence” component of source control was already taken care of for us. In other words, we were young and carefree.

After I left college and started working, the need for source control was explained to me and I was introduced to Visual Source Safe, a product so bad that even the company that made it didn’t use it for source control. Still, it was better than no source control. If I messed things up badly I could always go back to a sane starting point and life would be good. This was no perfect solution, but I began to see the benefits of backed up work and concurrent edit management in a way that I never had in school. I was moving up in the world and making some mistakes, but the good, honest kind that spurred maturity and growth.

As the 2000’s and my development projects went on, I was exposed to CVS and then SVN. This was a golden age of tooling for me. I could merge files and create branches. Rolling back to previous versions of software was possible as was switching to some speculative sandbox. It was easier to lead projects and/or scale them up to more developers. It even became possible to ‘rescue’ and improve old legacy projects by adding this kind of tooling. The source control schemes didn’t just become part of my subconscious — they were a pleasure to use. The sky was the limit and I felt that my potential was boundless. People expected big things from me and I was not letting them down as my career progressed from junior developer to seasoned programmer to leader.

The Gathering Storm

But storm clouds were gathering on the horizon, even if I didn’t realize it yet. In just a matter of a few short years following my promising career start, everything would change. My coding style grew sloppy and haphazard. The experimentation and tinkering that had previously defined me went by the wayside. My view on programming and software in general went from enthusiastic to apathetic to downright nihilistic. So I became lazy and negatively superstitious. I had fallen in with the wrong crowd; I had started using Rational Clear Case.

It started harmlessly enough. I was introduced to the tool on a long term project and I remember thinking “wow, cool – this separates backup from change merging”, and that was the sweet side it showed to sucker me in. But, I didn’t see it that way at the time with my unbridled optimism and sunny outlook on life. The first warning sign should have been how incredibly complicated it was to set up and how difficult it was to use, but I just wanted to fit in and not seem stupid and lame, so I ignored it.

The first thing to suffer was good coding practice. With Rational Clear Case, it isn’t cool to do things like add files to source control or rename existing files. That’s for nerds and squares. With Clear Case, you add classes to existing files and keep filenames long after they make sense. If you don’t, it doesn’t go well for you. So, my class sizes tended to grow and my names tended to rot as the code changed. Correctness, brevity and the single responsibility principle weren’t worth looking dumb in front of Clear Case, and besides, if you cross it, it gets really angry and stops working for hours or even days. Even formatting and boy-scout changes weren’t worth it because of the extreme verbosity in the version tree and spurious merge conflicts that might result. Better to touch as little code as humanly possible.

The next thing to go was my interest in playing with code and experimenting. VPN connection to Clear Case was impossibly slow, so the days of logging in from home at oddball hours to implement a solution that popped into my head were over. Clear Case would also get extremely angry if I tried to sandbox a solution in another directory, using its View.dat file to create all kinds of havoc. But it was fine, I told myself — working after hours and learning through experimentation aren’t things that cool kids do.

And, where I previously thought that the world was a basically good place, filled with tools that work dependably and helpfully, Clear Case soon showed me how wrong I was. It exposed me to a world where checkins randomly failed and even crashed the machine – a world where something called the ALBD License server having a problem could make it so that you didn’t have to (in fact couldn’t) write code for a day or two. My eyes were opened to a world where nothing can be trusted and no one even knows what’s real and what isn’t. I came to question the very purpose of doing work in the first place, since files sometimes just disappear. The only thing that made sense was to do the bare minimum to get by, and maybe not even that. Clear Case never tried to drown me in stupid, idealistic fantasies like source control that works and tools that don’t radically hamper your productivity — it was the only thing in my life that told me the truth.

Or, so I thought.

Redemption

As it turned out, I had strayed — been led astray — from the path of good software development, and my closest friends and family finally staged an intervention with me to show me the kind of programmer that Clear Case was turning me into. I denied and fought against it at first, but realized that they were right. I was on the path to being a Net Negative Producing Programmer (NNPP) or washing out of the industry altogether.

At first I thought that I’d have a gradual break with Clear Case, but I soon realized that would be impossible. I had to cut all ties with it and begin a new life, re-focused on my developer dreams and being a productive member of that community. While it seemed hard at first, I’ve never looked back. And while I’ll never regain my pre-Clear-Case innocence and youthful exuberance, my life is back on track. I am once again productive, optimistic, and happy.

What’s Wrong With You, Erik?

Okay, so that may have been a little After School Special-ish. And, nobody actually had an intervention with me; I actually just worked on projects where I used different source control. And I never actually stopped working at night, factoring my classes, giving good names, etc. So why did I write all of this?

Because Clear Case made me want to stop doing all of those things. It made many, many good practices painful to do while creating a path of least resistance right through a number of terrible practices. It encouraged sloppiness and laziness while discouraging productivity and creativity, and that’s a problem.

This blog isn’t about product reviews and gripes of this nature, so it isn’t specifically my intention to dump on Clear Case (though if ever a tool deserved it…). Rather, the point here is that it’s important to evaluate the tooling that you’re using to do your work. Don’t just get used to whatever is thrown at you – constantly evaluate it to see if it meets your needs and continues to do so as time goes on. There is something to be said for familiarity with and mastery of a tool making you productive, but if you’ve mastered a crappy tool, you’re probably at a local maximum and you need to go exploring outside of your comfort zone.

Subtle Signs That You’re Using Bad Tooling

I’m going to phrase this in the negative, since I think most people have a pretty reasonable concept of good tooling. That is, if something makes you much more productive/happy/etc, you’re going to notice, so this is really about the difference between adequate tooling and bad tooling. Most people recognize bad tooling when it simply doesn’t work, crashes a lot, etc, but many will struggle to recognize it when it kinda works, you know, most of the time, sorta. So here are subtle signs that your tool is bad.

1. You design process kludges around it (e.g. well, our IDE won’t color code methods, so we name them all Methodxxxxx()).
2. You personify/anthropomorphize it in a negative way (e.g. Clear Case doesn’t like it when you try to rename a file).
3. You’ll cut out ten minutes early at the end of the day specifically to avoid having to use it.
4. You google for help on it and *crickets*.
5. Developers on your team re-implement components of it rather than using it.
6. You make excuses when explaining your usage of it.
7. Bringing a new user up to speed on your process with it takes a long time and causes them to look at you disbelievingly or sadly.
8. People don’t use it unless forced or people attempt to use other tools instead.
9. You google the product and find more angry rants or posts like this one than helpful sites and blog how-tos.
10. People on your team spend time solving the tool instead of using the tool to solve business problems.
11. You think about it a lot when you’re using it.

So When is Tooling Good?

Apart from the obvious shouting for joy when using it and whatnot, there is a subtlety to this as well, but I think it’s mainly tied to item (11). A good tool is one that you don’t think about when using. For instance, I love Notepad++. I use it daily and quite probably hourly for a wide variety of tasks since it is my goto text editor. But the only time I ever really think about it is when I’m on a machine where it isn’t installed, and I get stuck with the regular Notepad when opening a text file. Notepad++ and its use are so second nature to me that I hardly ever think about it (with the obvious exception of when I might want to learn more about it or explore features).

If you take this advice to heart and want to constantly reassess your tooling, I’d say the single best measure is to see how frequently or infrequently you notice the tool. All of the other symptom of a bad tool bullet points are certainly relevant, but most of them are really fruit of the tree of (11). If you’re creating kludges for, making excuses about, googling or personifying a tool, the common thread is that you’re thinking about it. If, on the other hand, the tool kind of fades into the background of your daily life and allows (and helps) you to focus on other problems, it is helping you, and it is a good tool.

So don’t let Clear Case or anything else steal your innocence or ruin your life; don’t tolerate a tool that constantly forces you to think about it as you battle it. Life is too short.