Tom Ball's Blog

Tom Ball is a software engineer at Google, working on Java development tools. He has been working with Java since 1994 as part of the JDK, AWT, Swing, Jackpot, and NetBeans teams, and is a contributor to the JavaFX Script compiler team. Tom considers programming a craft, and is always looking for new tools and techniques to improve it.

Distributed SCM: You Don't Get It Until You Got It

Chris Adamson recently blogged, "what are the advantages of distributed SCM, beyond the globe-spanning mega-projects?" I've been hearing that question for a long time; it started whenever a new engineer joined a Sun project and had trouble getting their head around TeamWare. But it's hard to answer that question except with, "try it for a while and you'll see."

The reason that's a hard question to answer is because a distributed SCM creeps up on you and changes the way you work, in a subtle way you don't notice until you have to work on a single-repository SCM again. The reason is that branching is very easy on a distributed SCM and so you use it all the time; it's so easy that you rarely notice you are branching. Anytime engineers want to work on something independently, whether it be in different cities across the globe, between co-workers, or just by themselves working on two projects at once, all you do is clone the repository you want to work with from some other copy, which becomes the parent of your new copy. Make any changes you like in this copy, then commit them when you like them as usual. Just like any other SCM, right? Wrong, as the commit only happens in your copy; you need to merge your copy with its parent to share it with the parent's other child repositories.

It sounds like more work, but it's the opposite because it fits better with how most software engineers go about their jobs. Child repositories can work as safety nets, so you can try wild experiments and if they don't work, just delete their repositories (and no need to broadcast your failures with the world like with a branch in a single-repository SCM). Independent bug fixes need parallel code reviews? Just keep them in separate repositories and there won't be any risk of accidentally changing them before they are merged. A couple of team members are working on a side-project? Just copy a repository to hold your shared work, then copy individual ones so you don't step on each other. As time goes on you'll find you are cloning copies all over the place, and your productivity improves since your SCM system supports how you juggle your responsibilities.

Most source control management systems support branches, but the big difference with a distributed SCM system is that branches don't have to be explicitly created since you are always working on one or more branches. Branches with single-repository systems can be a headache many team avoid whenever possible; SCM advocates may claim otherwise, but that's been my experience working with CVS, Subversion, and Perforce. Developers are conceptually branching and merging as they write software all the time, whether it be in big teams or as individuals, so their version control system should make branching and weaving as easy as possible. It's counterproductive for a tool to fight the natural way most of us work.

It reminds me of when I got my first pair of noise-canceling earphones. I put them on, didn't hear anything different, and thought they were useless; but after wearing them for awhile, I took them off and was shocked at how loud my "quiet" room really was. I couldn't hear the normal noise until I grew accustomed to quiet.

It's that "fighting the flow" issue which makes it so hard to make the case for distributed SCM systems. When you start using a distributed SCM, it may seem to be the same experience as a single-repository SCM, and so what's the big deal? The "it's a big deal" moment happens when you switch back to a team using a single-repository, and then you find that not being able to easily branch and merge is a constant irritant and productivity drain.

Oh, and I forgot a reason why even Chris might make the switch: distributed SCM systems work fine off the grid, such as on airplanes. Try doing that with your java.net CVS or Subversion-based project!

It's All Just Bits

I was recently interviewing, and found that while some things have changed in the fourteen years since I last jumped companies, a lot is still the same. Recruiters still can barely spell Java or C++, let alone adequately screen a developer with those skills. Still, they (and the pointy-haired bosses working with them) are able to dream up a litany of all the hot technologies they just read about in Business Week magazine. Good luck actually finding someone with all of those qualifications (and who is able and willing to do the work for $50K ;-).

I've never been able to pass this recruiter hurdle, however, because I tend to work on whatever project is most needed at the time, rather than on what up-and-coming technologies might beef up my resume. What's kept me employed is a network of people who know that an engineer who can contribute to a team creating solid products is much more important than having someone who knows the hot technology of the month. And a belief we share is that it's much easier for an engineer to learn a new language, platform, framework, whatever, than it is to turn some buzzword-compliant tech wannabe into an engineer. Happily, my new employer, Google, understands this difference; that's why they are looking for engineers who are good bit-slingers since, let's face it, they have a LOT of bits to sling.

I think the difference is that real engineers know what's under the hood for any digital technology: at the lowest levels, it's just bits, ones and zeroes, no mystery. No matter how esoteric some platform abstractions are, at the end of the day they run on processors twiddling bits in interesting ways. Those layers of abstraction we all so carefully craft are essential for managing the increasing complexity of today's software, but it's easy to forget that when a layer is posing a seemingly unsolvable problem, we can always reach beneath it to piece together a solution.

That's why I don't agree with the current "testing rocks, debugging sucks" meme that is floating through our community, as both skills are essential for a good engineer. Yes, testing is essential for verifying software in an easily repeatable manner, and that the best first step in fixing a bug is to write a regression test that duplicates the problem. But good debugging skills which can look under the hood when necessary are essential for truly understanding what the problem and the right fix are.

I'm probably biased because one of my early learning experienced used a Heathkit 6810 microprocessor trainer, because you have to do the problems in not C, not assembler, but raw machine code. Firmware, linkers and loaders are all easier to understand once you've distilled a program down to a list of hexadecimal numbers. Robotwar was another fun learning experience; it may not have had me writing real assembler, but I learned quickly to debug all new code on its test bench or risk watching my mistakes blow my robot up in the arena.

My suggestion to new developers is that no matter what technology you are working with, regularly dig into how it is implemented because what you don't know now what may bite you later. Use a debugger regularly and have source code to the libraries it depends on, so that it's easy to step through the hard-to-understand areas. And when that layer is understood, dig deeper when you can. In the end it's all just bits, and good engineers regularly remind themselves of that fact.

JavaFX Preview Releases -- A Chapter Closes

Today the JavaFX Preview SDK released today, marking the end of an incredible year-plus for the JavaFX Script compiler team. It's been quite a ride, which has been played out for the world to see on our project's email aliases and JIRA issue tracking system. There are still changes under consideration for the language and runtime for the 1.0 release, but the SDK is much more functional than its "preview" name suggests.

If you are running Windows or Intel Mac OS X, then download the SDK and kick its tires. But what if you run another platform, such as Linux or Solaris? That's where we can help, as the compiler project's build server makes continuous and weekly builds available which are (should) run on any platform running Java 6. With full source available, of course.

And what's next? Just like those commercials which asked world series winners what they were going to do next, my answer is "I'm going to Disney World!".

October 2008

Search this blog:

Categories

Archives

September 2008
July 2008
April 2008
November 2007
July 2007
May 2007
April 2007
March 2007
January 2007
November 2006
September 2006
August 2006
June 2006
May 2006
March 2006
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
December 2004
November 2004
October 2004

Recent Entries

Distributed SCM: You Don't Get It Until You Got It

It's All Just Bits

JavaFX Preview Releases -- A Chapter Closes

This work is licensed under a Creative Commons License.