RAV4 Trip Report

First of all, I purchased my 2007 RAV4 4x4 V6 Limited for one major reason: fishing trips. I have to drive this car to work every day, so I could not afford (fuel) to go for a heavy 4x4 vehicle like the FJ Cruiser or some Jeep (see also, reliability). I wanted this car to be able to go up into the woods on camp roads and logging roads, to ford small (4" or so) water flows and generally handle well both on and off road. There is a fairly strong tradition in Maine toward beating your car to death (a.k.a "pushing vehicles to their limit") and so nearly as many family sedans are seen up in the woods as larger trucks. Adhering to this tradition I had a Mazda 626 LX before and stuck it in the mud on camp and logging roads a few times. After the last trip hurt my poor Mazda, I had enough...

The guys and I had a trip to the woods all scheduled for last weekend (Thursday to Sunday). Part of the trip was to get camp ready for the summer, part of it was to do some too early fishing and part of it was to test out my RAV4. It rained and it rained and it rained in the week or so before the trip, ensuring the unpaved camp road would be a mess. Then it rained a few more days right before the trip to be sure. We threw a comealong, towstrap and lots of stout rope in the trucklet along with fishing gear and other essentials.

The camp road was a terrible nasty mire complete with rocks and ruts and mud galore. All of the normal cars were left at the end of the camp road and yours truly in his sweet little RAV4 drove back and forth on the camp road ferrying people and baggage to the little camp in the woods. After several days of proof positive that my little RAV4 was a stout hearted thing, we went full bore. We attached the eye-bolt to the front of the car, hooked rope to it and pulled down a tree we were cutting up for firewood. Can you say, woohoo!

Now I know this isn't a real off-roading vehicle, nor do I have any plans to go rock climbing in the desert or seriously mudding or fording rushing rivers. It does appear to do an ample job of handling "light" off-road situations where a normal car simply cannot handle the conditions. I know for certain that my Mazda would have been stuck last weekend because someone else got stuck on the camp road and we drove up in the RAV4 to pry them loose.

If you have any plans for the same kind of activities in a 2006-2007 RAV4, I must strongly recommend you purchase one of those canister shields. I was power washing the car this morning to get the wheels back in balance and the dried on mud removed, when I remembered the canister shield. It was absolutely caked with mud and had a number of nasty scratches on it. The canister is clean and unharmed and all of the cables are undamaged and fully attached. Whatever that shield is protecting would probably be laying on the camp road without the shield, so my money was well spent. Nice work, mcvitie!

Scottish Rite Degree Team

Last night, Triangle Lodge No. 1 in Portland had the distinct pleasure to host the Scottish Rite Degree Team. The Team was decked in the costumes from the 20th Degree "Master ad Vitam", a.k.a. The George Washington Degree. There was a great crowd on the sidelines and everyone had a wonderful time. R.W. Bro. Jeffry Simonton was in the Oriental Chair for the evening and showed his excellent skills as always.

Next on the agenda at Triangle Lodge is a "Presiding Masters" Degree. More on that later.

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

In the Wake of Madness

Whenever I take a longer flight, as I did a few weeks ago, I always purchase a book from the bargain block of our local bookstore (Nonesuch Books). This time I selected an engaging book called "In the Wake of Madness: The Murderous Voyage of the Whaleship Sharon" by Joan Druett. While sailing the whaling grounds of the south Pacific the captain of the Sharon was murdered by a few mutinous crewman. The single handed recapture of the ship by the Mainer Benjamin Clough was so well known it was reproduced in a stage play. The book is extremely well written and leaves the reader with a sense of the vagaries of whaling in the mid nineteenth century. The best line of the book:

"Whaling captains were men who left their souls at home."

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.

Dell Inspiron 6400

My sweet new Dell has finally arrived, complete with Core2 Duo power (woohoo!). I did notice a weird problem when closing the lid, even temporarily. The windows would resize and reposition as if the screen size was changed to 800x600. I searched and searched and came up with this answer:

Fix: Close lid on laptop changes screen resolution
and
Annoying problem when close lid action set to "do nothing"

All is well now!

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!