ACCU, Day Two

The intellectual feast begins today! The keynote, by Tom Gilb, earned a pretty ruthless reception by the audience, particularly when he referred to there being no resources for guiding large projects with Agile. He indicated a book would be forthcoming, meanwhile the woman two rows in front of me rose to say the book had already been out for four years. She wrote it! The general level of hostility rose over time to be sure.

After the keynote I went to the session "Santa Claus and other methodologies" by Gail Ollis. The focus here was to explain how to evaluate and select methodologies. There was a particular focus on detecting flaws and salesmanship in methodology training. I wonder if part of the problem of software development is that we are still having trouble refining working processes, rather we always tear down the temple and rebuild it anew. I am guilt of that myself, but as we focus more on refactoring and less on rewriting from scratch shouldn't we apply those principles to our methodology development? The session was rock solid and worth attending.

Having being lakosed the night before I went back to my room for a nap, but wound up talking to the family instead. iChat, with its built in video conferencing is just wonderful! Better rested, though hungry from having skipped lunch, I returned to the conference for the remaining two sessions.

"Snowflakes and Architecture" by Steve Love was quite interesting on two levels. First, I realized that we are not as well educated in the language and practices of modern software design as we ought to be. There is still a lot of resistance to interface based programming, a style which results from the dependency inversion principle, except as it applies directly to COM. I have often wondered if the aversion to interface-based programming is a classic baby-and-the-bath-water reaction. Since COM was both inflexible and slow it may well have ultimately bred resistance the very core of its programming model. The wrap-up of the presentation was a description of the "hexagonal architecture", now commonly called the ports and adapters design. All in all a very engaging and interesting presentation.

The final session paid for the entire trip, insomuch as I am concerned, it was "Error Handling and Diagnosability" by Tony Barrett-Powell. He is a maintenance developer with Oracle responsible for a particularly gnarly multi-threaded service. Handling, reporting and analyzing errors is, as he says, "Really, really important to me" or "I am really serious about this." The Play State object is particularly interesting for for tracing the progress of database transactions and then reporting detailed diagnostic information, when used in conjunction with dynamic logging levels, the value to *******, where I work, is particularly valuable. Since we sell a very database-intensive application which works with user data, the part we rarely have access to, the information provided to tech support and/or development would be invaluable. He also made reference to "Patterns for Generation, Handling and Management of Errors" (PDF and More ... PDF) which I fully intend to search out and read.

As Steve and I were both exhausted from our lakosing the previous day, we snuck off to The Plough, a pub around the corner from the hotel, for a quiet dinner.

(Pictures soon on Flickr)

ACCU, Day One

Finally the conference was due to begin! Steve and I were conducted to the Oxford Paramount in time for registration and our first sessions. I had signed up for Tom Gilb’s “Evo” seminar. We, at *******, used Evo several years ago for a number of projects. While it did a good job managing the detail level, it generally fell down for long term project management. For instance, with Evo we were never able to answer: How is the project against its total schedule? There were also defects in the small software application used to store the task, or time box, level estimations. There were a number of great ideas we took from Evo, however, including choosing a lower available effort level for a developer. Our Evo tutor, Niels Malotaux, encouraged us to limit “effort hours” available per week to twenty six.

While this seminar did provide some very useful insights, Gilb was too self-aggrandizing and too negative about other methodologies. I did like his shift away from the old Evo time boxes, six hours per task as we were taught, and toward “front room” and “back room” development. More than that the idea of establishing measurable, stakeholder-focused benchmarks in conjunction with requirements development. In our case, at *******, we could apply this concept to record the time of several common GIS edit operations and then set a goal for improvement by the next release of the software. A particularly time consuming task in **** is copy-and-paste from one layer to another. We are able to measure the time it takes to transfer a collection of objects from layer A to layer B for our internal customer, then set a goal for improvement. This type of operation is extremely frequent and would have immediate value for both internal and external customers.

After the seminar I changed into my suit and made for The Alfred Lodge on Banbury Road. The Oxford Masonic Centre is a very large facility with multiple lodge rooms along with conference rooms and dining halls. The large hall was quite beautiful with several pieces of 19th century furniture including the painted stands used by the Master and Wardens (pictures soon to be on Flickr). The Junior Warden, assisted by another Brother, examined me that I might proved myself as a Freemason. Afterward we made for the in house pub where I had a soda, since I wanted to pay attention to every detail of the ritual, and was treated as a long lost Brother. The ritual that evening was a double Entered Apprentice Degree which was sufficiently distinct from the American version as to be only mildly recognizable. The concepts are still almost the same, but the language is completely distinct. Unfortunately, there was not enough time for the lecture expanding on the symbolism of the tracing board.

Following the degree work we adjourned to the dining hall for the Festive Board. I have enjoyed this dinner, similar in Maine to our Table Lodge. The most moving and engaging part of the Festive Board was the chain and Entered Apprentice’s song. The song itself can be found in Anderson’s Constitutions of 1723, but the ritual really added a great deal to the moment. I reminded the new initiates, as well as all of the brethren, of our obligation to reach out and assist our brothers. I was allowed the honor of giving the response from the visitors.

My experience at The Alfred Lodge reminds me of the simple power and beauty of the Craft. No matter where you go in the world, you are not without friends. I hope to be able to share the chain ritual and song with my own Grand Lodge, perhaps encouraging them to renew this ancient practice.

After lodge I went back to the hotel and shared a birthday pint with Steve. Unfortunately, it was not “soon to bed” as I was soon lakosed.

England, Day One

We arrived at 9:30am to a cool, gray skyline with a drip of rain here and there. It looks much like you would expect England to, although last year, thanks to global warming, the weather was gloriously warm and completely precipitation free. We grabbed our bags and made for the exit.

Lucky for me I was traveling with and real Englishman, Steve, who steered me away from the taxi stand, my preference, and onto the London Tube: mind the gap! We took the Tube from Heathrow to Earl's Court and then walked the remaining three blocks to our hotel. The walk was exhausting for me since I had brought toys, more on that later, leaving me in the larger bag with no wheels. The Hilton Olympia looks to be a 1960-1970s era hotel which has been mildly refitted, but is not particularly beautiful. After we dropped our bags off we wandered down Kensington High Street looking for Vodafone, SIM cards, and a pub, ale and lunch.

The young lady at Vodafone, Natalie, was helpful and had us up and running in no time. Steve was given an unlocked Nokia by a fellow at work while I was given a monster Sierra Wireless. My phone was a beast: slow, high power drain, bad cell reception and complicated. Steve lucked out in a a big way. In the end, however, we were able to call each other and numbers within the UK which was the critical goal.

Must of the rest of the day is a complete blur, owing to my being so tired. We had a lunch at a pub off of High Street on Kensington, wandered around a bit and then settled into the warm leather chairs at The Warwick Arms.

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

ACCU 2007 Day 2

Towards Simple Code: A Workshop on the Value of Simplicity in Software
Giovanni Asproni, Kevlin Henney, and Peter Sommerlad

This workshop was oriented around "The Laws of Simplicity" by John Maeda. The three workshop coordinators shared responsibility for explaining the laws of simplicity and the keys of simplicity as well. To learn about the laws, check the Laws of Simplicity web site. We then broke into teams charged to brainstorm up our guidelines for simplicity. The team I participated in wrote a number, but culled the group down to three key points:

1. We believe that minimizing information lifetime is a Good Thing(tm).
2. We believe that restrictive coding standards are counter-productive because they remove options before you even consider them.
3. We believe that Design By Contract improves code quality by making assumptions explicit.
   

The second point received the most questions. I explained the belief by asking people to reflect back on times they have had to reformat a method or module to make it readable. Thinking hard about that moment, was that necessary to do because of the code format or because of the lack of logical structure to the code itself? As the people in the room, we developers, when reflecting honestly, have to admit that we almost never reorganize code because of its format, but because of its poor logical organization.

It is interesting to note that few of the other teams applied simplicity to their own presentations, leading to quite long lists with relatively little explanation. This workshop was excellent and is one of the elements I want to share with the folks back at work. To see the results of our work see ResultGroupG.

Introduction to Component-Level Testing
John Lakos

This two-part session is nearly impossible to summarize, but suffice it to say that this three hour experience made the entire trip worthwhile. The core idea of the talk was that the physical organization of the files composing your project(s) is just as important as the logical organization of the classes. This idea is often and easily overlooked by developers, especially more senior developers. In large projects the physical organization of the projects often takes a back seat to the logical organization, if it is even considered at all. I am happy to report, that at DeLorme, we woke up to this reality some years ago and have been organizing our projects according to their dependencies for some time. Our hierarchy could probably use some expansion, but confirmation of our decisions certainly felt good.

As a side note, within five minutes John mentioned Barbara Liskov's Substitutability Paper and the Open-Closed Principle within five minutes of each other. This before the computer science session tomorrow. This is for you Mike!

Another wonderful point he made was about the cost of test driven development. He theorized two teams, both were given the same problem. The first team got right to the work and finished in two weeks and entered QA for an unknown time. The second team started writing tests, then the backing code. After two weeks they were 50% done. Which team is further ahead? Does it even matter? You know the second team has two weeks of work remaining, whereas the first team has an engagement with QA which will last an unknown amount of time.

He moved from design to testing at this point with an exhaustingly brilliant survey of component-level testing techniques. His first example was along the lines of "bool isOne(int value)" and his second example was Jeff Howe's famous countBits() function. Depending on the algorithm used, and he showed several, the testing requirements can be quite different. The largest complexity test results from the lookup table implementation for that function.

This is another talk which I want to share with people at work and it left me positively dizzy with information overload. John was a brilliant, skillful presenter who packed at least a week of information into a mere three hours. I imagine it will be several days before I fully appreciate everything he set out for us. This huge presentation again made the entire trip worthwhile.

Grumpy Old Programmers

Steve convinced me to attend this panel discussion with promises of hilarity. It was alright, but somewhat less uproarious than its reputation.

ACCU 2007 Day 1

The Pendulum of Software Development
Mary Poppendeick

The keynote was delivered by one of the two presenters from the pre-conference session I had attended yesterday. She covered a history of software development, primarily her own background, from 1960 to 2000. Then moved on to a few slides repeating her themes from yesterday: Stop-the-Line-Quality, etc.

Coaching Software Teams
Michael Feathers

This presentation was amazingly good, and Michael has a quiet an unassuming manner which imparts power to his points. A key initial point which formed a foundation for the talk was that you cannot expect everyone on a team to share the same level of commitment. Essentially, while you can help people rise to a new technical threshold, changing their commitment level is difficult and probably not worthwhile. They key question he asked us is, "Would you do your job if you were independently wealthy?" I certainly would and so indicated, but there were a very few people in agreement.

Another approach he uses for working with teams is to imagine the entire team as a single person or "Pat". He then works to understand Pat's personality and emotional state, which is essentially the personality and emotional state of the team as a whole.

The discussion then moved on to how to actually coach a team. He was careful to note that nearly all coaching should be done with individual teams rather than to the team as a whole. The most teachable moments, in his experience, are when the tension, similar to but not always stress, is high. The reception of the lesson taught resolves the problem and disipates, or releases, the tension. This tension/release cycle was another frequent key phrase during the rest of the presentation.

He then spent a fair amount of time reviewing about fifteen or twenty specific coaching techniques. There were several very interesting ones, including a somewhat strange idea called "The Flounce." He told a story about a team which had worked hard to improve their process and quality, yet management continued to feel as though it was not enough. The team felt terrible about the problem, but no one would openly admit it. Another coaching consultant came in to help the team and noticed immediately what was wrong. Rather than just come out and say it, he brought the team together and said there was a huge problem, then did not name it. As people made suggestions he kept saying, "No. That's not it." increasing the tension within the team. Finally, someone came out and described the problem with management's expectations and the team released and worked to resolve the problem.

Finally, the discussion moved on to thorny issues in coaching: ethics, personality conflicts, and cliques. Anyone who has coached a team has run into these issues at one time or another and his suggestions were both concrete and useful. One of the more interesting titles he mentioned in the presentation is "Teamwork is an Individual Skill" by Christopher J. Avery. I have put in a request for this text.

Fingers in the Air - A Gentle Introduction to Software Estimation
Giovanni Asproni

This presentation was quite interesting and reviewed many things I already knew about software cost estimation. There is clearly no new "silver bullet." I did find his suggestion that you use multiple methods if at all possible. He said: count, measure, then judge. This meant we should first attempt to estimate by counting something (KLOC, function points, etc), failing that by measuring something (story points, complexity), and as a last resort by expert judgment. If making an estimate by this last process obtain two or more different estimates.

I realized that I had often heard elements of this presentation in talks by another Software Architect at DeLorme. Welcome to the "Cone of Uncertainty."

Linting Software Architectures
Bernhard Merkle

This presentation is almost impossible to really evaluate. As a baseline all of the presentations are one hour and thirty minutes. That is quite a lot of time, but with an interactive audience can burn away pretty fast. Bernhard's presentation was about sixty minutes of general discussion about exploring architectural defects. The material was simply too basic for Steve and I, but we hesitated to say anything for fear there were less experienced folks in the audience.

One core technique he used for architectural linting of existing systems was to create a representation of the expected architecture. Then reverse engineer the architecture from the code and compare the two descriptions. This allows you to detect differences between your expected architecture and what was actually implemented.

After burning up two thirds of the session with little or no interruption due to questions, he started to describe some tools. These descriptions used screen captures from running the various tools on publicly available Java systems: JDK, Ant, Eclipse, etc. This information was genuinely valuable, but felt as though it came too late.

Suddenly, with but one minute to go in the presentation interval, he broke out actual live copies of each of the tools. The disappointment was almost palpable. Everyone in the room would have loved to see the tools themselves an hour ago, rather than during the last sixty seconds of the presentation. In the end, the presentation was enormously useful, but just not all that well organized.

ACCU 2007 Day 0

Steve and I signed up for the full day pre-conference tutorials at the ACCU 2007 Conference. Steve signed up for "C++ Productivity" by Hubert Matthews, which he enjoyed very much. One challenge from the session was to write a complex calculator program in C++ as fast as possible. Steve leveraged his experience with SPIRIT and whipped one off in short term. You can see why we all think so much of his work. Brilliant, as they say here.

I attended "Lean Software Development" by Tom and Mary Poppendieck. The presentation discussed techniques for applying the principles of the Toyota Manufacturing System approach to software development. Many of the essential concepts were familiar to me from my use of Neils Malatoux's Evo Methodology. 'Lean' also makes use of timeboxes, frequent releases, and early testing. One of the key points made during Mary's section of the presentation was to stop maximizing local productivity and start maximizing system productivity. Essentially, rather than having each developer at maximum capacity, developing both immediately useful and prospective (not immediately useful) features, look at why it takes so long to get a particular feature from the concept stage to the release stage.

She was also very, very firm that feature requests from customers and sales should be processed immediately and turned into code as soon as possible. I asked a number of questions about this issue, but never gained what I considered a satisfactory answer. There was a frequent recourse to the traditional new systems attitude: "if you do it, you will see". While I see many of the related points, I wonder if the approach is so oriented around web projects and internal IT projects that there are limits to the application of it to large scale commercial software. For example, she was quite strident that requests from customers should be filtered, accepted or rejected, and then worked on as quickly as possible. For a small scale or internal project, I imagine this would work pretty well. For a very large customer base with a huge volume of input from many sources, this is both impossible and not particularly desirable. There were also discussions in the tutorial that this approach may not dovetail with the sales cycle and other business processes.

There were several really key items which I found a lot of value in. The distinction of products and projects and team organization was very interesting to me. I am used to the project-style of organization, which is a frequent style for smaller companies with multiple products. Mary made some excellent arguments about the value of product rather than project orientation. I am interested in exploring some of these ideas at work.

Tom took over with a discussion of software quality. I agreed often and significantly with much of what he had to say about unit tests, acceptance tests, and so forth. Having successfully tried test-driven development, it really works for new projects. It is difficult to use in the context of a large, legacy code base and it also is difficult to keep doing it without a team organized around that principle. One project we worked on wound up with more tests than code. It has been a big help to the quality of the project. Tom suggested we look into the "fit framework" for automating acceptance testing.

While I am not sure I would attend their track again, I certainly learned a few things.

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.