Performing without Rehearsal: No Thanks

Would you perform in a play without any rehearsal? Perhaps if the play were a monologue on a topic you knew inside and out? Of course, I think even then, I’d practice my skit in front of a mirror or some friends and family. I’d at least try my luck with the dog or cat!

Preparation seems like a given, especially for large/important projects. In addition to preparing for something of importance or complexity, it’s always good to do a “dry run” to see how things will go. This applies to technical projects/tasks as well as things like performances in front of an audience. Odds are, you’ll have an audience; it just may be a horde of users for your system. It’s better to work out the kinks and automate as much of the process as you can.

So, imagine having to upgrade a piece of open-source software that your team heavily customized through several years of significant version releases. Suppose the client was afraid to allow you to perform any upgrades for years as they tacked on more and more customizations to the existing codebase. After all, it’s been working all this time. To make matters worse, suppose many of these customizations had to be made to the core code due to the youth of the version in-use. Now, finally, you are allowed to upgrade to the latest version. It’s going to be a nightmare, but you have a plan…in your head.

You know that a rehearsal is in order. In fact, there are so many things that need to be rewritten in order to work with the latest version of the customized software, you just know that problems will appear during the process. So, it makes sense to “perform” the “play” on the base software and database before any of that code is rewritten and re-integrated.

What Really Happens?

You know what really happens in this story; don’t you? Yeah, you do. The coding begins first. A fresh installation of the latest version of the software is used to rewrite all those customizations properly. Then, after a lot of effort is sunk into the coding, somebody thinks it’s a good idea to upgrade the data (no doubt this is huge amounts of data); the rehearsal.

The “performance” is a disaster! The data won’t upgrade; most likely due to all those customizations that slowly worked their way into the bytes somehow. Now you’re stuck with the old version of the software until you can figure out what is preventing the upgrade. There is way too much data to make it easy, so the process could take months, if your client even opts to bother now.

What’s worse? The coding for the upgrade is nearly finished! So, what if the client decides to cut-and-run on the upgrade? All that coding could be discarded; thrown away. Is it your team’s fault for not insisting on performing the rehearsal first? Is it the client’s fault for pushing hard to get the upgrade done and wanting to see their custom features in the new system quickly?

I wouldn’t be the one to answer those questions. I sure as hell wouldn’t be the one to say, “I told you so!” No, that would be a bad idea.

What’s the Moral?

Push hard for what you know to be the right path to a successful project; no matter what that project may be. Have I seen the above “story” happen several times in my career? Yep. Would I feel bad if I experienced the same again? Probably a little, but I’d feel a lot less remorse because I would shout about my experiences if necessary to be heard.

Decision-makers, listen to your experts. Clients, you are decision-makers, so the preceding fully applies to you. However, if you choose to ignore the advice of your experts, don’t expect them to sympathize with your plight. More importantly, please don’t make the ensuing backlash their burden to bear alone.

Git vs. Mercurial


Git is fast, efficient, and not too opinionated. Throw-away branches are a plus (and a minus). With this feature, you can create a feature branch to try something out or work on a new feature in isolation. When you’re done, you can merge the branch back to master/dev/whatever, and delete the branch. In fact, this methodology is prescribed. It’s as if the branch never existed. That can be great, but there are down sides. Knowing the true history of a feature branch has advantages, and you’ll miss out on them if you delete it. If you’re okay with that though, Git branching rocks.


Git is certainly great, but lacks polish when dealing with its users. If a command has 3 primary uses, and 1 is used 90% of the time, 1 is used 8% of the time, and the last is used 2% of the time, wouldn’t it make sense to make the most used scenario the default for the command? Why is it that so many Git commands require the most used scenarios/options of that command to have so many switches, yet the least used scenarios are the default switch-less version of that command?

Prefer a GUI over the command line? Don’t you ever tell a Git lover that you prefer a GUI for managing your repositories. Just, don’t even bring it up; you’ll get flogged! However, you do have options. GitHub for Windows is excellent software for visualizing your repos in, well in Windows. SourceTree is another great application for working with Git (and Mercurial) in Windows and Mac. But, again, just don’t bring up the fact that you use a GUI for Git. It’s just safer if you keep that to yourself.

Remote Hosting

Sure, you can host a remote repo on your own server, but there are much friendlier options. GitHub is the de facto standard for hosting Git repos and sharing them with others. They support public repos for free, which is great for open-source projects. Bitbucket added support for Git repos after solely supporting Mercurial for quite a while. Now, you can host either type of repo and as an inverse to GitHub, Bitbucket supports private repos for free. Kiln is another great hosting provider for Git (and Mercurial). You can even use Git and Mercurial interchangeably with repos stored on Kiln (which is simply amazing).

Mercurial (Hg)

Mercurial is fast, efficient, and a bit opinionated. Most people will have a difficult time finding real noticeable differences between Git and Mercurial. The absolute biggest difference is branching. Mercurial doesn’t really have a concept of throw-away branches. That is, once you create a branch in your repo, it’s there for keeps. You can get rid of branches with plugins or cloning around the revisions that include the branch. However, having permanent history is actually a strong point for persistent branches in Hg. When you look back through the history, you can actually see where the named branch revisions came from, and that can provide insight into the origins of that code. If you need to work on an experimental branch that may not make its way into the repo, you do have a recommended option; clone the repo and work in the clone for the experiment. If your experiment doesn’t pan out, delete the clone; if you decide to use the code, push it back to the original repo and merge.


Mercurial is more friendly to non-Linux systems and their users. Yes, I’m vaguely nodding to Windows here. Typically, the commands for Mercurial have sensible defaults, so you’re not constantly hunting down what options you need or constantly typing just to execute a simple command. Installation is also a breeze.

If you prefer a GUI to the command line, there are very nice pieces of free software available. TortoiseHg is a favorite (Windows only). Hailing from the days of TortoiseSVN, this product integrates with Windows Explorer, but now supports a stand-alone client for managing all your repos in one view. Let’s not forget the new kid; SourceTree (by the folks behind Bitbucket) is an excellent Mercurial (and Git!) client that runs on both Windows and Mac. They are catching up with features found in TortoiseHg, but while quickly doing just that, they are also providing unique features (and workflows) to a great application.

Remote Hosting

Again, you can host your own remote repo; Mercurial supports that option. However, Bitbucket offers free hosting for private repos and their system is just outstanding (you can also host Git repos with them). Kiln is another wonderful hosting option for both Mercurial and Git. As mentioned above, you can even use Mercurial and Git interchangeably with repos hosted on Kiln (your team members can use whatever they are comfortable with).

Which is Better?

Really, the appearance of distributed version control systems was a tremendous turning point for developers. Everybody has a full copy of the entire repository as a local copy. You can work offline and sync later. Each developer can act as a makeshift backup of the shared repo. Branching/cloning allows for safe feature trials that can be selectively merged into more stable branches.

Git and Mercurial resolve to the same end; a very efficient history of all your project’s changes over time. It really comes down to your preference of branching strategy and sensible/insensible defaults for the available commands. So, which is better; Git or Mercurial?

Nice try! There’s religion, then there’s politics, and right behind those are programming languages and tools. If you state that one is definitely better than another, you set yourself up for a war. However, we do all have an opinion. Mine is for Mercurial, but that’s just me. I use both extensively on many projects, so I’m not just talking out of turn.

Note: I won’t tell you that your preference is wrong, so do me a favor and don’t tell me that mine is either. Besides, if you’re really nasty about it, I’ll never approve your comment. ;-)