Installation at Cumberland Lodge

This evening I was pleased to be able to assist in the Installation of Officers for Cumberland Lodge No. 12. The new Master for the year is Wor. Bro. Kurt Ringrose, a co-worker at DeLorme who contributes significantly to the product I oversee, so it thrilled me to be able to participate. The evening flowed very smoothly with Wor. Bro. Steven Cobb as the Installing Master and two experienced Past Masters assisting as the Installing Marshal and Installing Chaplain. Wor. Bro. Cobb performed very well particularly considering it was his first crack; he was far less nervous than I on my first attempt! I installed the Wardens and Secretary along with doing the candle charges for the Master and Wardens. A great time was truly had by all, which is to be expected for a lodge with so many young, excited officers! Wor. Bro. Ringrose is set to have a great year in the Oriental Chair.

So many Maine Masons have witnessed the installation ceremony without knowing much about its history. One of the earliest versions of the installation ritual can be found in Wor. Bro. William Preston's seminal work "Illustrations of Masonry" in Book 2, Section 6 "The ancient ceremonies of the Order". Though it is not quite the same as our ceremony, you can see our roots in its structure and language. Much of what Preston wrote way back in 1772 is still part of our installation today.

To all of the students of Masonic ritual out there, what was the next edition of the installation and why was that ritual so important in the 18th century?

Cognitive Advantages of AccuRev

I was having a discussion about AccuRev and branching today at the office. We are still transitioning some projects over to it, so there is some development using SourceSafe and some using AccuRev. The effort required to maintain even a minimal isolation with two branches is hugely largely than the same task in AccuRev. In the midst of this discussion a thread about complex branch management and traditional SCM systems was brought to my attention. Just look at the images on the Microsoft Branching and Merging Primer. The graphs themselves become steadily more difficult to understand as you move from simple branches down to code-promotion and component branching.

Meanwhile, a project I am managing right now, in AccuRev, is actively using both code-promotion and component (sub-project branching). We have the classic Product_Rel->Product_QA->Product_Int streams which allow us to ensure development is stable before moving issues to QA. The QA department can verify the changes function before moving them to Rel. The release build is then an aggregation of all of the features which really work together.

Additionally, we have three streams below Product_Int for sub-projects. First, is a stream for merges from a product developmed in VSS. We promote changes from it in cohesive groups, but only as time permits. If this stream gets out of sync with its parent, we take note of overlaps and resolve them in the merge source stream without destabilizing the Product_Int stream. This permitted us to merge little bits at a time over a period of four weeks. We also have a stream devoted to refactoring a specific subsystem. It too is able to take advantage of overlap notification to stay in sync with its parent. Finally, we have a time-locked stream which we use to service an internally released tool. This structure, though technically more complex than those depicted above, is far simpler for us to maintain and use; even for people who do not eat, sleep and breathe SCM. Why?

After some thought this is what I wrote to the person who pointed out the primer:

The thing I have been noticing is that people with AccuRev perceive "branches" differently, more as a natural feature of a source tree. I sincerely believe that is a result of the visualization provided by the stream and versions browsers. They arm people with a clear cognitive model, whereas the old folder and file approach can only effectively visualize branches as folders, just like everything else. The result is that AccuRev users can both depict and describe a complex branching structure much more easily, and users of traditional systems generate crazy graphs which do more to obscure the branches than illuminate them.

Visions of the Future

We were fortunate to receive two visits from Damon Poole, founder of AccuRev, to discuss the use of AccuRev at DeLorme. I remembered speaking with Damon several years ago at SD East, and it was that conversation which made me interested in what AccuRev had to offer. This meeting was no less impressive.

We discussed our experience moving from Visual SourceSafe. The SCM part of our transition was minor, but our move from a 1980s era massive build system to continuous integration was huge. We changed nearly everything about how we manage the code for projects, largely due to our greater flexibility with AccuRev. Since making large changes is so simple with AccuRev, we opted to address items which had been on the todo list for years. Damon asked a lot of good questions and clearly saw this painful transition as something AccuRev could help other companies with. Be that as it may, I would not trade my experience from November to March for all the tea in China.

Damon then took some time, in both meetings, to break out what he terms "concept cars." These are very much like real concept cars in that they indicate, in a general way, where a company is going but the concept vehicle and the final production vehicle are usually different. He walked us through three PowerPoint presentations which outlined several important future areas of development for AccuRev. Though we were hardly sworn to secrecy, I feel the need to be a little vague here. The research tool, which we saw first, looks extremely powerful with features I know will be useful during the bug hunt, but more especially for release engineering.

The dashboard tools he showed, however, got the biggest reaction from me since it appealed to me both as a developer and as a tech lead. During the demonstration there was a point when I just blurted out, "Once this tool comes out, you can pretty much just start printing your own money." Trust me, if you are an AccuRev customer you will be buying this add-on. Meanwhile, the rest of the world is going to be beating a path to their door. Suffice it to say, that at the end of the meeting our super smart, hard dealing Department Head said, "How much?" and "When can I cut a PO?" Unfortunately, this software is not yet in the can, but perhaps we can jump into the beta program for it. In any case, the vision of the future looks great for AccuRev, since they are not a company who is going to rest on their laurels.

That reminds me...I should make a t-shirt on the front: "AccuRev Old School", on the back a picture of the dashboard concept design and: "I used AccuRev before they went double platinum".

On the Bike of Madness

For the life of me I will never understand why I agreed to this, but Chip persuaded me to join Team DeLorme for the Trek Across Maine. Though I used to commute two miles to work, when I worked in Portland, I have probably never biked further in a single trip than ten miles. Now, owing to my stupidity, I have to manage to bike at least sixty miles per day for three consecutive days. Fortunately, Tandy, the triathlete wife, has agreed to help me out by taking the sixty miles in day two. My other saving grace is that soccer is going to start up next week, which goes a long way to building up my stamina.

The first task is to come up with a decent bike. I am planning to borrow a bike from Chip, but I realized I have a nice Schwinn up in the attic of the garage. I will probably take it down to Back Bay Cycles for an evaluation. If they think the bike has potential I am going to replace the handlebars and make a few other changes.

The state of things is best summarized as "excited, but nervous."

DeLorme and AccuRev Press Release

The press release reporting DeLorme's purchase of AccuRev came out earlier today. It took poor Alex Forbes some time to pin me down for the interview, but he did a great job with the write up. The old SCM system had to remain nameless, but its behaviors have made it clear it isn't all that safe for our sources. One item in the release was particularly interesting:

"...AccuRev increased productivity by eliminating broken builds, and teams that were unable to access the previous SCM repository for 24 hours at a time while a new build was created are now able to work continuously...." (says I)

Since we only did night builds, if a build broke you had to remain careful about what changes you pulled down from the SCM repository. You never knew if the change might force you into pulling down code which had failed to compile and was therefore in an unknown state. Back in the pre-AccuRev era we actually had little certificates of "Build Breakage" or "Build Dalekage" with various levels of severity based on the number of errors. If you broke the nightly build(s) you could be relatively certain of finding one of those certificates on your door in the morning.

With AccuRev, however, we can grab revisions based on a particular transaction number. This allows a developer to look at the Continuity Build, if it is green they can take the reported transaction and run "accurev update -t transactionID" to update their workspace to that known safe point. I look forward to seeing that feature moved from the command line to the GUI in a future version of AccuRev. Now broken builds are more rare and when the do happen are localized and visible within a very short period of time.

ACCU Conference 2007

This year, I have opted to attend the ACCU Conference in Oxford, England. The conference was strongly recommended by my co-worker, Steve Nutt, who attended last year and is actually from Oxfordshire. Judging from the session information, the conference will be quite unlike any I have ever attended. After nine years, Microsoft has certainly adjusted my expectations to the informational depth and access of the PDC (Professional Developer's Conference). The topics certainly interested me a great deal, as did the opportunity to travel outside of the United States. Thus far I have only been to Niagara Falls, Canada a few times, which felt like a pretty sanitized any-town tourist destination. Something tells me Oxford and London are going to be quite a bit different than my trips to Niagara Falls and Disney World.

On Tuesday I will be attending the pre-conference seminar "Implementing Lean Software Development" by Mary and Tom Poppendieck. I have high hopes of visiting Thames Lodge No. 1895, part of the Provincial Grand Lodge of Oxfordshire, on Tuesday evening after the conference. I am presently in e-mail contact with a member of the Lodge, who has been very kind to assist me.

On Wednesday the conference really gets going with "Coaching Software Development Teams" by Michael Feathers, "Reviewing the C++ toolbox" by Alan Griffiths or "Fingers in the air: a gentle introduction to software estimation" by Giovanni Asproni, and "Linting Software Architectures" by Bernhard Merkle.

On Thursday the selections turn even more difficult "Choose your Poison: Exceptions or Error Codes?" by Andrei Alexandrescu or "Towards Simple Code" by Sommerlad, Asproni and Henney, or "Stop-the-Line Quality" by Mary Poppendieck, then either the two part "Introduction to Component-Level Testing" by John Lakos or "Pattern Connections" by Kevlin Henney then "Typical Pitfalls in Agile Software Development" by Jutta Eckstein.

On Friday I really, really want to go to Bjarne Stroustrup's talk on the Future of C++, but if I skip "The Appliance of Science: Things in Computer Science that every practitioner should know" by Andrei Alexandrescu, then I'll never hear the end of it at work. I already take enough heat during the morning caffeine intake sessions for my use of computer science terms like "substitutability" (go Liskov!) and "subsumption". Doesn't "parametric polymorphism" just roll off the tongue? Then I am going to listen to the first 45 minutes of "CUTE: C++ Unit Testing Easier" by Peter Sommerlad then sneak out at 2:45pm to see "Continuous integration: what it is and why you should use it" by Ivan Moore. Finally, having totally missed the chance to hear Bjarne speak on the future of C++, I will go to the two specific C++ Futures sessions which really call to me "C++ Threads" by Lawrence Crowl and "Standard Library report" by Alidsair Meredith.

The last day of the conference arrives with Saturday. The morning session is impossible with my candidates including "Making New Friends" by Dan Saks or "Renga: Conceptual Integrity and Collective Code Ownership" by Nat Pryce and Steve Freeman or "Concepts: An Introduction to Concepts in C++0x" by Doug Gregor, but then the last session is no question with "Meta-Intelligent Design" by Phil Nash.

After all of this information my brain may really be mush! It is pretty essential that I have the chance to hear Bjarne Stroustrup speak, perhaps I will see if Steve and I can switch. He goes to hear Bjarne during the computer science session and I will go to hear him during the Continuous Integration talk. In any case, this conference promises to replace quantity with quality. Normally I have several time blocks where there are no interesting sessions at the PDC, keeping in mind that this is a conference with at least a dozen concurrent sessions. At the ACCU most time blocks have at least two or three interesting sessions.

Embarrassingly enough a major topic of conversation between Steve and I has been what to wear. Aside from the fact that I know next to nothing about the weather in England, I was also not sure about the politics of the group. Just to be contrarian, I will wear my John "maddog" Hall t-shirt to the PDC or my "Real Programmers use Visual C++" t-shirt to the Java Users Group. Are Microsoft t-shirts safe here? Should I kick it old school with some SGI gear? What is a geek to do? In any case, I do plan to wear my AccuRev shirt to the conference!

AccuRev Shines Again

When I started as a developer, there was really no such thing as "connected" development. The environments I wrote code in were often astounded by tools as primitive as RCS, so "disconnected" development was beyond imagination. At DeLorme we used Visual SourceSafe for many years. It was a great tool for small team development and worked well for us until our level of concurrent development skated right past its capabilities. We had a heck of a time managing disconnected development owing to the manner in which VSS was tightly coupled to file sharing. We tried a number of packages, such as Source Off-Site, but they never quite caught on here (no idea why).

I often work like mad on flights to and from professional conferences. For some reason being away from every distraction is a perfect environment for me to design and prototype or just work through thorny code. At the last Microsoft Professional Developer's Conference (PDC'05), I was coding up a storm for our new GIS importer architecture for what would become XMap 5.0. Even with all of the disconnected editing support in Visual Studio 2003, the experience was still unpleasant. VSS kept raising up and getting in the way. When I found a low-level problem, delegating it to a gifted developer back in the office meant a difficult update in the hotel room.

On Sunday, I was sitting on an airplane working on the new architecture for our GIS exporter module when I ran into a problem in a low-level string library we maintain. Just like the PDC trip, I wanted to delegate this back to the office so the unit tests would be updated to check this case at every build. I patched the problem and sent the email off to someone back at the office. Now AccuRev had a chance to really shine. I kept my changes to my private workspace, allowing that developer to test out my particular case without promoting my unstable code to the integration build (win #1). When he had made the changes to the string library and it passed unit testing and the integration build, I threw my temporary changes away (win #2) and brought his changes down with a single click (win #3). Everything built as perfectly here in San Antonio, Texas as it did in Yarmouth, Maine (win #4). Now I am able to work on some ideas I picked up at the conference with a nice, clean build (win #5). The very heart and soul of disconnected development.

AccuRev is a great product. It managed to both facilitate our processes and improve them without a big religious conversion associated with other development tools.

AccuRev and Merging Bliss

Normally, I do not post to my blog from work, but I just had an AccuRev is awesome moment I needed to share. Under the previous software product, sold by a very large company which provides operating systems for most of world's desktops, merging was a horrible experience. This unnamed "safe" product for "source" code would often duplicate merged blocks, leading to code which looks right, but fails to compile. The most horrible situation you can imagine in this older, "visual" product is a double merge. You make code changes, combine with another branch and then have to combine with a third branch. This almost never worked in the old days, leading to a development process which tried to prevent such situations from occurring.

Then the clouds parted and the glorious sun which is AccuRev beamed down on us. To set the scene, we loaded our 100,000 or so source files from the old system into AccuRev some two months ago. Since then we have converted to Visual Studio 2005 and shifted toward a continuous integration system. Suffice it to say there have been lots of systemic changes to our codebase. Meanwhile, development continued in the old source control world and we wrote scripts which aided in conversion. Periodically, I would load updates from the old system into AccuRev and ensure consistency. Now two months later the last of the changes are being loaded into place, and a wonderful event occurred.

I have a file, call it foo.c, with changes from the old system. I loaded it into AccuRev and ran a keep on it, conceptually similar to checkin, but in a private workspace. I compared it to the previous revision and used "Merge From" in the "Browse Versions". In the old world, this would be a migraine-inducing experience, but in AccuRev the two versions folded together in a few seconds. When the merge was complete and the "Browse Versions" window displayed again I found that a developer had just promoted their own changes to the file while I was merging. In the old world, on a Friday, I would have given up and gone for a beer leaving the problem for the weekend. Never having faced the situation in AccuRev, I turned up the music and readied myself for disappointment. I selected the new revision and chose "Merge From." The resulting file was perfectly merged, all of the changes were correctly select and the resulting file is perfect.

Honestly, it took me longer to write this post than it did to load, back merge and forward merge this heavily altered source file. Even after carefully reviewing all fifty-eight perfectly combined changes.

Just in case it isn't clear...AccuRev is the single best piece of SCM software I have ever used. An excellent combination of easy to use and powerful.

[No, I do not work for AccuRev. I really do work for DeLorme as a Software Architect. I do, however, totally love this SCM system.]

Visual Studio and AccuRev

It has been a while, but work grabbed me with little more than a week between two large projects. We shipped out XMap 5.0 and I jumped right into the selection, purchase and install of new development tools. The upgrade from Visual Studio 2003 to Visual Studio 2005 was actually quite a bit more painful than the upgrade from Visual Studio 97 to Visual Studio 2003. The improved ISO C++ compliance is conceptually great, but when you have a fifteen year investment in C++.... Well, suffice it to say that we realized we had a fair amount of non-compliant code kicking around in the repository.

The more engaging part of this task was replacing our weather-work Visual SourceSafe 6.0d source control control system with AccuRev. We last evaluated AccuRev when 3.5 was the current edition of the software. (cue wavy lines)Back then its integration with Visual Studio (a.k.a. SCCI support) was pretty rough around the edges and the AccuRev Client GUI needed a bit of maturing. The worst part of that eval process was being able to see just how great a heart they had to the product. Rather than select a lesser SCM system, we cancelled the upgrade project a decided to wait... (back to reality) This time through, under AccuRev 4.5, they really spent some time and effort on their SCCI support and client GUI. Everyone on the analysis team was really wowed by the product, so much so, that some of us could not wait to get our hands on it. Though it has not occurred every day, at least a few times a week I run across another great feature which makes me shout, "I love AccuRev!"

The new software packages are finally being deployed throughout the department this week. Hopefully, I will have time to return to my other pursuits. The in-laws bought me a book on Esoteric Freemasonry, which will be a great way for me to start learning about this branch of the Craft.