Stories about Software


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. 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. 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.


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.

  • http://twitter.com/dotnetchris Chris Marisic

    That list of 10 Signs That You’re Using Bad Tooling is spot on

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks — glad you liked. Unfortunately, the list is born out of more experience than I’d have liked working with bad tooling…

  • Pingback: The Hard Switch from Walking to Driving | DaedTech()

  • Andrzej Rehmann

    God I hate clear case. After we moved new development to Git I still get nervous when changing or creating files. The fear after using clear case for 2 years will stay with me for many years.

  • dave404

    Our development platform that connects to our device is on the PC and hour Clearcase vobs are on Unix. On the PC Clearcase is unreliable and it amazingly slow, sometimes half an hour to “checkout” a file for writing. So we sync with unison and integrated it with our environment. So we use secure ssh passwordless login to control the PC while on Linux with his remote syncing. Much better but why do we have to do this. Because CC sucks.

    Better yet once we have imaged our code base on the PC, why not copy it to another directory, remove the Read only BS and do real work. Next with cygwin installed do a git init, Presto I have a bootleg git. Then push that to our local git hubs that are company controlled. Presto a high performance environment, until the next rebase comes.

    This seems like a small price to pay for the speed. Too bad only two of us are doing this and I cannot get buy in from the rest.

    The approved way is to stay in Clearcase where we have two streams with 5 developers working on them (this is one small feature group in a huge company), you plan your checkouts and use findmerge to merge in the versions of files you need. Hopefully you are not editing files in the same view as I as the other day. LOL. What a joke. I want to retag my workspace, I need to check out the project file. I need to change a compiler option, check out the project file. I instrumented my code to debug but had to check it out and I was stuck in loop instrument, oopps need to rebase, uninstrument, rebase, instrument, repeat over and over. They gave us a book “A Clear Case for Clearcase”.

    The days of sneakernet and thumb drives was better than clearcase.

  • http://www.daedtech.com/blog Erik Dietrich

    I can definitely relate to that. It makes you gun-shy with what should be basic, no-brainer source control operations for a long time and, what’s worse, it instills bad practices (delay check-ins/merges as long as humanly possible).

  • http://www.daedtech.com/blog Erik Dietrich

    Man, I’m sorry. And Amen to your last line. I’ve often thought over the years that I’d take a file share and versioned folders as ‘source control’ over Clear Case.

  • Peter

    Oddly enough, my experience with ClearCase is totally at odds with the original post – When I used it (about 10 years ago now), I found that it was powerful, stable and enabled one to do anything at all (including adding/removing/renaming files) with confidence (unlike CVS or SCCS, which didn’t even cope with renames at the time).
    However, I only ever used ClearCase in a unix environment (Sun Solaris, writing in C/C++/Java), with the ClearCase server being on the same OS, i.e. no Windows/PC involvement anywhere.
    It worked well in a unix environment as the CC data appeared as a mounted filesystem; it “just worked”.

  • http://www.daedtech.com/blog Erik Dietrich

    I can’t speak to what it’d be like in a pure *NIX environment. My only exposure to it was in .NET environments that were all Windows, including the servers.

  • http://typingcat.blogspot.com/ Sin Jeong-hun (신정훈)

    A SCM is supposed to be there to help developers… but ClearCase took so much time from me for dealing with the SCM itself.

    The office I worked at was a small office with about 60 developers (the company itself was a large multinational one), and we had a dedicated ClearCase administrator and several expensive servers for CC. Still, it was really really slow. The GUI was so bad and sometimes crashed without any specific reason. Creating a baseline and recommending it was such a pain that we created a command-line tool to do that by one command and yet it took several minutes to complete.

    I do not exactly remember the licensing fee, but it was damn expensive, and yet, the GUI looked like they have stopped developing it since1997. The GUI was never improved from when I first started using it (2009) till I stopped using it (2014). It looked as if IBM had spent more time in preventing software piracy than actually developing the software itself. According to the words I heard from the CC administrator, CC first checks for license with a remote license server for “every” transaction. What an overhead. Rebasing took several minutes within the GUI in lucky cases.

    Some of my colleagues said CC was actually a really well-written software, but I do not care. I hated it, because it was so terrible to use it. It is like a car with a very efficient engine and internals but has terrible seats, an unintelligible dashboard, and a fractured windscreen.

  • http://www.daedtech.com/blog Erik Dietrich

    I suppose Clear Case might have been “well written” back in the early 90’s when it was written, but it certainly hasn’t aged well, as you point out. When it comes to IBM software, it always feels like IBM takes all of the money that could be earmarked for product development and puts it instead into funds that their salespeople use to bribe CTOs that don’t understand software at the ground level. You only ever see Clear Case at companies where developers don’t have a say in their own tooling.

  • davidgiga1993

    This was just the best article I read for a long time. I also have to work with CC on a daily basis and it’s just horrible. Even though the new ClearTeam Explorer has some features I missed in the old one like recursive checkin (welcome to the 20th century IBM!) it’s still horribly slow and just unusable managing large amounts of files (large = more than 10 files). As I’m working on a few projects on my own I’m currently using git locally and zip the project once per week so I can check it in clearcase. Which brings us to point 8 of your list, which is also just spot on!

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks! Glad you liked.

    I have to be honest — I’m floored that they’ve made a “new” product to lay over the top of that rotten foundation. I just assumed that all of IBMs budget here went to wining and dining CIOs and they’d just keep milking the existing, 20 year old infrastructure indefinitely. I’m not sure whether I credit them for trying or not.

    I wish IBM would do the right thing and pull the plug on it.