It was Italy this year...

My wife and I traveled to Italy this year for our annual vacation trip. We flew via Atlanta to Milan where we stayed for 1 night at Hotel Spadari which has a great location near the Duomo cathedral. We then took the train to the Lake Como area, where we stayed for 6 nights at Al Veluu Restaurant and Suites. They have a beautiful setting above Tremezzo -- there are only 2 suites above the restaurant. We were early enough in the season for things to be pretty quiet. It was a 10 minute walk down the hill into town. While in the area, we toured the gardens of several of the nearby villas, and otherwise enjoyed the food and scenery. 

The gardens at Villa Carlotta were very impressive... we had timed the trip in hopes that gardens in the area would be in full bloom, and we were not disappointed... absolutely gorgeous. The Lake Como area has its own 'micro' climate -- they have palm trees, and cactus, and azaleas, and giant sequoia (not too giant yet), etc.... a real botanical mash-up. For a day trip, we took the bus over to Lugano, Switzerland. Who would have thought to find palm trees in Switzerland?

From Tremezzo, we took the bus to Como, where we caught the train to Milan, where we took the train to Riomaggiore -- one of the Cinque Terre  towns on the Italian coast. We rented the Marco Polo suite for 5 nights. It was a great location with a great view overlooking the town. We hiked all the trails that were open (the one between Corniglia and Vernazza was still closed due to rock falls). Cinque Terra is touristy but not built up with anything particularly modern looking. It's one of Rick Steve's favorite parts of Italy, which contributes to the crowds, but also helps keep the towns in business.

We'll probably go to Greece again next year (Crete and Santorini), but this Italian iterlude was worthwhile -- it's beautiful country.

Language Defects

One of my pet peeves with the English language is the use of possessive pronouns. For example, 'my' is typically used to mean ownership, as in I am writing this on 'my' computer. But what word must we English speakers use when we want to describe the relationship we have with someone else? The very same 'my' -- where now it defines a relationship instead of ownership, as in I love 'my' wife. Clearly, the relationship I have with my wife is vastly different than the one I have with my computer, yet in standard English usage, I use the same word for both relationships. This, I think is a defect of the English language. I wonder that other languages have the same defect, or if any languages don't have this particular language defect.

Another Greek Island Vacation

On Santorini, we stayed at the same place that we stayed last year: Anastasis Apartments . On Folegandros, we stayed at Kifines,on Milos, we stayed at Nefeli Sunset Studio apartments. All very nice.

Greece's financial problems had no affect on us. The Iceland volcano did affect some travelers from other European origins, so Santorini was a bit less crowded than last year. Overall, the vacation was a relaxing time, and was what we were hoping for.

Pictures are here. 

Managing Expectations

I got a support call the other day from a customer -- they hadn't yet received their license file, and were wondering where it was. In these days of instant online purchases, I suppose I might wonder too. How come it takes so long to get a license file? For new readers, this might come as a surprise, but Quma is a one-man operation... and for most of Quma's existence, it's been a part-time operation as well. As a result, I have to make tradeoffs when it comes to running the business. Among those tradeoffs is the balance between development, and business process automation. Where will my time best be spent? So far, it hasn't made much sense to automate the order processing side of things because there are not that many orders. So, each order is manually entered into our order database, and each license file is created 'by hand' using tools I wrote to generate the license files. Since Quma is a part-time occupation, those orders get processed in the evening.

I hesitated to compose this entry, but one management activity that has merit is the management of expectations. From my perspective, I think I'm fairly accessible for support issues, and am responsive to support requests, etc. But my perspective may not be the same as someone who is expecting something that I cannot provide... so in the hopes of managing expectations...:

In general, I respond to e-mail support requests from anyone within 24 hours. Precedence is given to customers, but sales support is available. Orders are processed within 24 hours, with the caveat that I can only process an order after I receive it. Sometimes NorthStar and/or RegSoft are slow in forwarding orders to me which can lead to delays. If you need support, I much prefer e-mail to phone support. If you do call, you'll typically be reaching me at my day job. I won't be in front of a computer, and so may not be able to provide a useful answer from memory... so please use e-mail if you can. The forums are useful, but you need to email me in order get approval to post to the forums -- I do this to prevent forum spam, which would otherwise be a major waste of my time.

The predator is an optimist

Evolution almost requires that predators be optimists, and explorers. How else could they survive? This insight occurred to me after watching some nature show that had a lion of some sort chasing prey -- and failing in the attempt... only to try again, and again, until successful. The lion, by nature, must persevere or die. They must look forward to success and plan for success, even if they often fail.

This observation offers an explaination for human's possession of an optimistic nature. Often our optimism is completely unfounded, but it is our nature to be optimistic, because failure is an option, but continuous failure is not.... If at first you don't succeed, try, try again... look on the bright side.... etc.

A Vacation to the Greek Islands

For vacation this year, we went to the Greek islands -- Santorini (5 nights), Naxos (5 nights), and then Athens (3 nights). We thoroughly enjoyed it. The views on Santorini... well, check out these pictures. We'll probably go back again next year. On Santorini, we stayed at Anastasis apartments. Highly recommended -- the staff is warm and friendly, and the views are great. On Naxos, we stayed here. It's not as up-scale as the place on Santorini, but the staff is friendly, and the location is great -- a short walk into Naxos town -- yet far enough from town to be quiet in the evenings. Overall, a relaxing time... that we hope to repeat (with some different islands) next year.

Make it easy to do the right thing...

One of the goals of good user interface design is to make it easy to do the right thing, and conversely, difficult to do the wrong thing. So the goal at Quma is to always make the right thing to do the easy thing to do. I don't always succeed, but that goal is usually in mind when adding some new feature, etc.

This same rule-of-thumb can apply also to institutions: good institutions make it easy to do the right thing, and difficult (or costly) to do the wrong thing.

Things go bad when you make it easy to do the wrong thing since most people choose to do the easy thing whether it's right or wrong. In software, there are typically few horrible consequences if the easy thing to do is the wrong thing to do – though I'm sure there are counter examples. In an institutional setting, making it easy to do the wrong thing can produce evil results. Among the horrific examples of this – imagine that you're a German citizen living during the WWII era. You're not some leader type, you're just a common Joe, trying to stay alive. The Nazis come to power, you're drafted, and now find yourself assigned to guard duty at Auschwitz. You thank your lucky stars you don't have to fight the Russians on the Eastern front. And then you're given the order to herd the Jews into the ovens. Here is an institutional setting where the easy thing to do (obey the order) is the wrong thing to do. Very few of us possess the moral fortitude to disobey – How many of the guards in the concentration camps knew they were doing the wrong thing, but chose to do the easy thing instead? The easy choice was to commit genocide; the difficult choice was to disobey and face an uncertain future -- either immediate death, or a trip to the Eastern front. The institutional framework was all screwed up.

A less horrific example from today's economic headlines – many bankers/lenders were aware of the sub-prime lending problem, and yet many of them chose to do the easy thing – continue to make bad loans. The bankers are not particularly stupid or evil – they are like most of the rest of us: when faced between a choice to do the right thing, vs. doing the easy thing, they chose the easy thing. The thing wrong with this picture is that the easy thing to do is the wrong thing to do. I'm not sure I could articulate all the wrong turns made that have put our instutions in their present state -- where in so many instances the easy thing to do is the wrong thing to do -- but it bears thinking about. If we're to ever get out of our current mess, one important step on the road to recovery will be to alter the design of our institutions so that doing the right thing is the same as doing the easy thing.

Kindle 2.0 first impressions

I got my Kindle 2.0 today. It was supposed to arrive on Monday, but the Post Office did something wonderful -- they delivered it a day early. I am pleased.

Some first impressions:

1. It is smaller than I expected. I know I could have taken the published dimensions and created a cardboard cutout to mimic its size to see what to expect -- but who has time for that. No complaints about the size -- just that it really is only a little bigger than your standard size paperback book.
   
2. It has a nice heft to it. It feels sturdy.
3. It takes some getting used to the difference between reading on the Kindle vs. reading a real book. Well duh.... but it will take a while to get used to the differences. My current expectation is that there will be some changes to the way people read a Kindle book vs. the way that you read a paper book.
4. The text-to-speech is the best I have heard.... not that I have made a study of products in that category, but the speed is good, and it is easy to understand.
5. At this point, I think the biggest thing I will like about the product is that it will let me carry around a whole bookshelf of books. The navigation between books is an area that could be improved -- ideally the device would have a touch screen -- but I think I'll be able to learn navigation tricks to make it second nature.
6. I put a couple of .pdf books on to the device (an easy enough thing to do, though it does require an e-mail round-trip to amazon) and -- aside from the footnotes -- the translation to Kindle format worked well.
7. For avid best-seller readers (I am not), I can imagine the immediate gratification of being able to get your hands on a bestseller in just 60 seconds will be the most addictive part of the Kindle experience.
8. My Kindle came pre-configured with my Amazon account, and a 'personal' thank-you letter from Jeff Bezos on the device; along with a book that I had ordered while the device was being shipped. Pretty cool, and pretty painless. Nice that they pay attention to those kinds of details. It's like a book appliance.... you just turn it on, and it works.
9. What will the secondary market for Kindle's look like?

Conclusion -- it's a thumbs up...

The Jean Dixon Effect

As our economic meltdown continues, it's worth stepping aside for some perspective.

I have no idea where the markets are heading. Professional pundits are paid to make predictions about where the markets are headed. Some of those pundits will actually be correct. Does this mean they genuinely understand the dynamics of the situation, or are they no better than the broken clock that is correct twice a day? I don't know the answer to that either.

I find it helpful to put pundits in perspective by invoking what I have come to call the 'Jean Dixon Effect'. For those of you old enough to recall, Jean Dixon  was a psychic who predicted the assassination of Kennedy. She became famous after Kennedy was shot, and some folks then began to think that she actually knew what she was talking about.

When markets move this way or that way, there will always be some market analyst who was on the correct side of that move. The talking heads then trot out their new found expert to get that expert's opinion on where the market will go in the future. Will that new expert be correct or incorrect? The Jean Dixon Effect causes us to view that expert with a less critical eye than we otherwise might.

As I think about this some more, we are also victims of the converse of the Jean Dixon Effect -- we ascribe misplaced expertise to those whose actions have demonstrated failure after failure. It's almost embarrassing to look at the predictions of soundness and stability earlier offered up by some of our leaders. Witness the early testimony of Paulson and Bernanke (say back in March of this year) on how fundamentals were just fine, etc., etc. The converse of the Jean Dixon Effect allows us to listen to these guys and still grant them some level of credibility.

The big question that I don't know the answer to: What will the Chinese do?

Back from Japan

Hmmm. I don't usually go 3 months between entries here.

In any case, we're back from a 15 day vacation to Japan. Most folks don't think of Japan as a vacation destination, and we didn't either. But our daughter was completing a semester abroad program in Nagoya, and wanted to finish up her stay over there by touring the country. So we headed to Japan to see the sights, and discover.... Heated toilet seats!

We flew into Nagoya, where we spent 3 nights at the Hilton. We visited with our daughter's host family -- they were gracious enough to treat us to a genuine Japanese eating experience at a Japanese restaurant -- complete with kimono dressed waitresses, grass mat floors, cook at the table boiled beef, and food, and food, and food.

Nagoya does not really cater to the tourist, but it was a good place to recover from the 13 hour direct flight from Detroit. We went to our daughter's 'graduation' ceremony -- and understood not a word of the presentation.

From Nagoya, we took the bullet train to Kyoto. The bullet train was kinda cool. They didn't have any kind of speedometer so there was no direct way to tell how fast the train was going, but it seemed really fast. In Kyoto, we rented a small 2 bedroom apartment that was less than 100 meters from the bus stop. The bus stop was just across the street from the local grocery store. For our typical day, we'd eat breakfast at the apartment, then head out to explore the various shrines/temples that Kyoto is famous for. We'd eat lunch out, then head back to the grocery store where we'd buy our evening meal to eat-in at the apartment. The bus system in Kyoto was easy to navigate and convenient.

From Kyoto, we spent almost an entire day traveling to the Japanese Alps, where we stayed at a 'Japanese plan' hotel in Kamikochi -- they provided breakfast and dinner, and we were on our own for lunch. The mountain view from our room was excellent. I'm not a big fan of Japanese food, but the hotel's efforts were worthwhile -- I ate sushi for the first time. Japanese breakfast is quite different than western fare.... lots of fish and rice. By the 3rd day I'd grown accustomed to it, and had grown much more proficient with chop sticks. The mountains at Kamikochi are beautiful and rugged. The biggest surprise while there were the crowds. Bus load after bus load of Japanese tourists traversed the 1-hour ride up the 2-lane road to Kamikochi where they would then flood the hiking paths along the river. Imagine being in the wilderness of a Yosemite with crowds like those of a Time Square and you're getting a partial picture of what it was like. The crowds weren't really that bad, but there were many, many more people there than I expected -- especially given the challenging drive up to the base of the mountain. We were there mid-week. I'm guessing that weekends are even more crowded.

From Kamikochi, we took the train to Tokyo, where we spent 6 nights. Tokyo is a huge world class city. We stayed at a small apartment west of downtown -- it was a 15 minute train ride from the apartment to Shinjuku train station -- the busiest train station on the planet. For scale, Shinjuku has as many people go through it on a daily basis as the entire population of Baltimore, and then some.... some estimates have as many as 2 million people through that station on a daily basis. Our apartment was right next to the train station, and also right next door to a large 24-hour super market. Though small for Americans accustomed to larger digs, the apartment was very convenient and workable.

In Tokyo, we discovered a great French restaurant: Tete a Tete. I don't remember the train stop as I write this, but it was along the 'Yellow' line, which was the main train that we'd use to go from our apartment to anywhere we wanted/needed to go. The prices were cheap (around $11.00 per person) for a 3 course lunch, including dessert.

We went to a Tokyo Giants baseball game. It was an indoor stadium. Very similar to a game in the US; very family friendly. We visited Akihabara -- a shopping district for electronics that just goes on forever. We visited the National Museum -- their analog to our Smithsonian. It was big, uncluttered, and busy... We took a day trip down to see some shrines in a town south of Yokohama... and we just bopped around Tokyo.

Some cool things that would be good to export from Japan:

1. I really could get used to heated toilet seats.
2. Their trains and public transportation are generally superb. The only delay we ever experienced was the result someone committing suicide by train -- i.e. apparently getting run down by a train is a fairly popular way to commit suicide in Japan... and our trip from Kamikochi to Tokyo was delayed for an hour by one of these suicides.
3. Japanese restaurants have a nice tradition of giving each patron a wet towel before the meal in order to clean your hands.

Another astounding 'good thing' in Japan is the safety and respect for property. This isn't something that can be exported, but to American eyes, it's just amazing to see elementary school kids traveling by themselves on the train system. People park their bicycles without bothering to lock them. The US used to have a culture that provided that kind of environment, and it would be great to see it return, but it's not so simple as installing a heated toilet seat.

Things that could be improved:

1. The Japanese have a completely inscrutable way of composing addresses. On one occasion, we were trying to locate a restaurant described in one of our guide books. We took the train to the general area of the restaurant, and then used the address from the guidebook to ask the locals where to find the restaurant. No one could tell us where the restaurant could be found... we kept trying for perhaps a half hour, and had to give up. All wasn't lost because the restaurant where we ate ate instead more than satisfied... but it was just hugely frustrating to discover that the 'street' address wasn't really very useful in identifying the restaurant's location.
2. Street name signs are scarce. Some American cities also suffer from this problem. In Tokyo, you can walk up to a major intersection, and find that neither street has any kind of sign to tell you the name of the street. This adds to the difficulty in finding your way around.

Overall, I think our trip to Japan was a success. The country was much less foreign than I expected. The people were friendly, the cities were clean, unpolluted, safe, and easy to navigate using public transportation. We've now marked off 'Japan' as a place we need to visit -- it was worth doing.

It always happens with a new release...

Whenever I publish a new product release, I get bug reports that point out problems that have existed for a long time. I suppose this is partly due to the closer scrutiny that a new release gets as users test it to evaluate whether it's worth their time or not. In any case, there are 2 problems that the new 2.1.10 release of QVCS-Enterprise has brought to light:

• In the 'checked in before' and 'checked in after' file filters, things work fine immediately after defining a filter collection that uses either of these two filter types; but fails with a null pointer exception if you try to use that filter collection after restarting the client application.
• In the built-in visual compare tool, the 'ignore case' flag was always ignored... i.e. while you could request that the visual compare ignore case in the compare, it would never ignore case.

Both of these bugs are now fixed in the code base, and the fixes will appear in the next build.

Googling Jim Voris

Occasionally, I'll 'Google' my own name to see what turns up. Lately, when I do this... yikes. (I won't supply the link, but you can try it yourself).

I don't live in Indiana , and as far as I know, I have absolutely no relation to the 'Jim D. Voris' listed as the first hit on Google's search.

The results point out some of the biases built in to the way Google sorts its search results: apparently government sources have a higher ranking that other sources, though it may just be that the page rank of that government site is higher than any of the other lower ranked sites that return hits for 'Jim Voris'.

In any case, for anyone who cares, my middle initial is not 'D'.

Web site refresh

We just refreshed the web site again; the biggest change this time is that the QVCS/QVCS-Pro manual is now online, in .html. You can get to the online documentation from the documentation page.

The plan going forward is to maintain the online documentation, and the product help file. We won't bother to maintain the .pdf file.

Web site refresh

We just refreshed the web site. Please take a look and let me know what you think.

We still have some tweeks, but to my eye, this is a big step in the right direction. A big thanks to my daughter who did most of the work.

Web site refresh coming soon

We're working to create a new look for the web site. I don't have any screen shots that I'd like to share, but I'm guessing the new look will ready sometime this weekend, or next weekend. I'll announce it here of course, and look forward to your comments.

Upgrading to FiOS

I upgraded to Verizon FiOS today. The speed is a bit better than Comcast cable -- one rough test showed a download speed of 7.4 mbs with FiOS versus 2.4 mbs for cable... and FiOS is $10 cheaper per month to boot. A friend has had FiOS for over a year, and heartily recommended it as reliable and fast. The fast part seems to be there -- though it doesn't honestly seem to be that much faster than cable. We'll have to see about the reliability. The guy doing the in-home install noted that there's no power on the stuff outside -- it's just glass, so there's nothing to short out, etc. It comes with a wireless router which was easy to set up... overall a positive experience. Imagine that.

Ignoring Sycophants

Suppose you're some rich/powerful person. How do you prevent being surrounded by sycophants. Communication between two people is difficult and often leads to misunderstanding. Effective communication between different levels of a hierarchy is even more difficult. How does a Bill Gates or a George Bush get an accurate picture of what is really going on?

Almost by definition, they can only talk to people who are already in their orbit... people who may be just as much out of touch with reality. I suppose they must come to rely on gathering information from more impersonal sources -- e.g. reading articles, books, etc. where the author isn't affected by the inclusion of a Bill Gates in the audience. If they rely on advisors instead of impersonal sources, they're likely to be told what they want to hear instead of the truth.

For impersonal sources to offer meaningful criticism, the target of their commentary must be transparent -- i.e. only if they have access to the same general body of data as insiders can they offer informed observations. Whether in government or large corporations, secrets serve to arm insiders with knowledge hidden from general view. Insiders have a vested interest in preserving the shroud of secrecy, since this gives them power to control the debate. A leader surrounded by secrets can rely only on advice from people in on the secret -- a population with a viewpoint guaranteed to be warped by the sycophants it contains.

Effective leaders have figured out this dynamic; less effective leaders have not.

UPDATES: Fix punctuation; fix spelling.

Back from Austin

We're back from a spring trip to Austin, Texas. Spring is a good time to visit Austin -- though I could have done without the tornado watches we endured on our final night in town. We stayed at the Brava House Bed and Breakfast. It's a superb location in a quiet neighborhood just minutes from downtown. The 6th street music scene is a long, but pleasant (1.5 miles) walk. The new marquee Whole Foods market is just a few blocks away, and other eateries are just as convenient. We had a great time exploring Austin, and the surrounding 'Hill Country' area of Texas. Summers there are brutal (all the local admit this to be the case), but this time of year, the weather was perfect.

Austin has Verizon broadband wireless coverage, so it was easy to keep up with e-mail and tech-support issues...

Now it's back to work on the QVCS-Enterprise 2.1 release. I've made the transition internally to using the new 2.1.4 release. I won't be making it public as it is still missing some key features (file delete, directory delete, directory rename, and directory move); but it does have the skeleton of views implemented, and I want to get some mileage on that before the public beta. I want to get file delete implemented before making anything public -- and for that, my current thinking is I'll have a 'technology preview' before the beta. The 'technology preview' will not be feature complete, but it will have the view stuff in place. I'd like to get some user feedback on 'views' sooner rather than later. Will users see it as confusing, or intuitive?

Stricter QVCS forum access

If you want posting access the QVCS support forums (http://qumasoft.ipbhost.com/ ), you'll need to jump through more hoops than in the past (Users who are already forum members won't see any change). For reasons that defy my understanding, QVCS support forums have undergone a sustained spam attack from folks who either want to waste my time (which may be their intent), or have some wild misunderstanding of what kind of message traffic I will allow to appear on a Quma support forum.

If you want to become a forum member, please drop me an e-mail (jimv at qumasoft dot com) as forewarning so I can let your membership application go through. If you are a registered user of any QVCS product, you'll just need to provide your registration ID. If you are not a registered user (why not?), then I'll be happy to let you on the forum if you can persuade me that you are not a bleep bleep spammer.

QVCS-Enterprise 2.0.18, and new box shots

QVCS-Enterprise 2.0.18 is available. You can find more details here. It's been out for a while, but I've only now gotten around to annoucing here on the blog... sorry for the delay, but I've been preoccupied with work on QVCS-Enterprise 2.1, and a short-term consulting gig that I've taken on.

Along the way, to the 2.1 release, I want to dress up the web site a bit, and to that end, a first step is to create some cooler graphics that I can use to represent the 3 QVCS products. I've always liked web sites that show their software products in 'box shots', even though the product is sold electronically... so I began to play around with a tool that would help generate nicely shaded box-shot pictures for the QVCS product line.

In a web search, I found an affordable, and simple to use product called (appropriately enough) Box Shot 3D. The only problem with using this product is that you have to have some artistic talent to create the images that it uses for the front and side of the box.... so I asked my daughter to put together something, and was major league pleased with the results:

How cool is that?

Hopefully, customers will understand that they'll never actually receive a box containing software...

These new box shots will be part of the new look to the web site -- and though it will be a while before the web site update actually happens, I couldn't resist showing these off.

Back from Florida

We're back home from a nice visit with my wife's family. This is the time of year to go to south Florida -- the weather was pleasant, and for whatever reason, the roads were not as crowded as they sometimes are at this time of year.

While there, we goofed off -- enjoyed Charlotte's Web and Dreamgirls.Charlotte's Web was a quiet/good kind of movie. We have the books-on-tape version of the story as read by the author E.B. White -- which is very good. The movie is faithful to the book, and does a good job of capturing the same tone as the book.

Dreamgirls was excellent. The only complaint is that the story would have been even more powerful had it been the true story of the Supremes instead of a fictionalized account. The music was good, but including some of the original tunes would have been real icing on the cake. My suspicion is that the authors/producers of the Broadway version couldn't afford, or couldn't acquire rights to the original story, or to the original tunes. In spite of that, the movie is superb.

I also took the time to read several paperbacks: Roses are Red, Violets are Blue, and The Eternity Artifact... all decent enough, but they don't stand out as books that I will remember.

More American history

The Wall Street Journal recently reviewed and recommended a new World War II historical novel by Jeff Shaara. Our local library bought lots of copies, but they're all checked out... so I opted to try out his 2 volume historical novel about the American revolution. I've finished the first volume (Rise to Rebellion) and have mostly finished the 2nd volume (The Glorious Cause). Both have been well worth my time. I'm not an expert on the facts, but reviews and other books I've read confirm the historical accuracy of the events portrayed in the books. What makes them different from most histories is the novelization of the main characters. This is where historians might have issue with the books' contents: an historian doesn't really know what Washington was thinking when trying to figure out what Howe's next move might be... but Shaara invents those thoughts and weaves them into the events that we do know. The result is something that is much more readable than a standard history book.

My current progress has taken me up through the beginning of 1780. As with other histories of the revolution that I've read, this one confirms the almost miraculous confluence of (now famous) men and events. Would the revolution have succeeded had we not had a Washington, Franklin, Sam Adams, or John Adams? Or on the other side, the mistakes made by Howe, Clinton, King George, et. al.? We'll never know, but the course of human affairs at the time was balanced on a very fine point, and all these actors had a huge impact on the way things turned out.

Technorati tags: Jeff Shaara, Rise to Revolution, The Glorious Cause

California Vacation

Here are a few pictures from our California trip. Click on the thumbnail here to get a bigger version of the picture.

This is from outside Sonoma. There are a lot of grapes in the area, and many wineries. Wine tours and wine tasting is a fun and relaxing diversion. We visited two different wineries in the area, and bought some wine. Because of Maryland's bizarre alcohol laws, we were not able to ask the wineries to ship any wine back home... so we carted a couple of bottles (all we could really manage for transport on the plane back home) with us for the rest of the trip.

I couldn't resist taking a picture of these signs, which welcomes visitors arriving on the ferry from San Francisco. I'm not real sure what a Cholesterol Free Zone is, but now I've been to one. We had a nice lunch in Sausalito overlooking the San Francisco bay. Lunch included good bread with butter (last I checked butter is a good source of cholesterol).... apparently the requirements of a Cholesterol Free Zone don't extend to restaurant menus.

This is the obligatory picture of the Golden Gate Bridge.We took the ferry from San Francisco to Sausalito, and then walked across the bridge from Sausalito to San Francisco. The day was clear and pleasantly cool.

From San Francisco, we headed over to Yosemite. This is me in front of some other folks who are standing on the precipice of a cliff that has a sheer drop of some 1,000 feet or so. When we first approached this vantage point, I crawled on hands and knees to the edge to look over -- and didn't do that again. These are the most impressive cliffs I've ever visited, and quite demanding of respect.... one slip, and you're dead. You can just make out a much needed railing on the edge of the cliff in the distance. You do not want to bring small children or unleashed pets here.

On the trail to Cathedral Lakes (in Yosemite). It had snowed maybe 1/4 inch the evening before. Yosemite is a beautiful park, but their trails are poorly marked compared to other parks I've been in... and their trailheads are not always easy to find. I'm not an outdoors expert, so maybe they make this stuff more difficult to discourage trail use by novices. Seems kinda counter productive. On one evening, when I was checking e-mail in the lodge lobby (where I had 802.11 access), I overheard the increasingly frantic efforts of one member of a group who was trying to determine whether other members of his group had made it off the trail yet. It was already dark, and his friends had apparently taken a wrong trail branch on their way down....easy enough to do since the trails are poorly marked. You've got to have a lot of respect for the wilds when out hiking, and I would not want to be caught unprepared to spend a night outside...

Here I'm pacing off the circumference of this giant sequoia. It was some 60 paces, which translates to 120 - 150 feet, or roughly 40 - 50 feet in diameter. That's a big tree. The giant sequoia's are a natural wonder. If you've never seen one, then put it on your list of things to see before you die. They stand as silent sentinals. The really big ones are old and gnarled and look eternal. After seeing them, it's still really hard to get my head around how big they are. Most impressive.

From King's Canyon and Sequoia National Park, we headed to Death Valley. Here I am at the bottom of Death Valley -- the lowest point in North America. Death Valley is aptly named. It's hard to imagine how anyone during the push west could have survived traversing this place -- yet they did. Thank God for air conditioning. In the summer, the average daytime high temperature is something like 116 degrees (Fahrenheit). The soil temperature gets over 200 degrees. It was actually pretty pleasant for this picture -- in the 70's.

This is looking down on the bottom of Death Valley from a place called Dante's View. From this spot, you can see both the bottom of Death Valley (at some 280 feet below sea level) and Mt. Whitney -- the highest point in the contiguous 48 states (at 14,494 feet). Dante's View is over 5,000 feet so the view you see here is like one you get from an airplane flying 1 mile above the valley floor.... that's a road down there.

From Death Valley, we headed to Las Vegas. I have pictures of Vegas, but won't bother posting them -- Vegas is a well known destination. We stayed in a hotel room on the 35th floor. The room had a balcony, with a decent view of the strip. Our hotel was connected with the MGM Grand casino -- so we could walk from our room into that casino without having to go outside. I'm not into gambling at all -- I just don't see the point, though I can understand how some other folks might find it entertaining. On our last night, we went to see a Cirque de Soleil circus show. I enjoyed it -- there was one act that had these two muscle bound white guys doing slow motion power lifts of each other. My wife and I were impressed -- we could both imagine how much strength was required -- a LOT... and they were smooth, no muscle tremors at all.

California is a big place -- and we just scratched the surface. We'll probably go back again sometime.

Back from California vacation

Back from a 16-day vacation to California.

We flew from Baltimore (BWI) to Oakland, picked up our rental (a red Jeep Liberty), and then drove up to Sonoma, north of San Francisco. Stayed there a couple of nights, then drove down to San Francisco for four nights. From there, we headed to Yosemite for four nights, and then on to King's Canyon (home of the giant Sequioia's) for 2 nights. From King's Canyon, we headed south, spent one night in Camp Nelson, and then one night in Death Valley. From Death Valley, we drove east to Las Vegas for our final two nights.

In all of this, we had Internet access (in some form or other) everywhere except Death Valley. Pretty cool. I wasn't able to get any development work done (it was a vacation, after all), but I was able to handle e-mail support questions, and keep up with issues on the forums (thanks Dirk for handling the PowerBuilder issues!). Over all, Internet access was more available than reliable cell phone coverage.

We're still digging out from all our junk snail-mail. The post office had to put it all in one of their large plastic tote boxes. I didn't bother to count the number of 'vote for me' pieces of junk mail we received... there is an election coming up soon, yet we were able to remain blissfully unaware of the numerous streams of hot air that elections seem to cause.

The measure of success for our vacations is whether we would change anything in our itinerary -- and on this vacation, things worked real well. Some of the places are ones we don't need to see again (e.g. Death Valley), but all the places we went were worth seeing at least the one time.

I'll try to post some pictures and cover more of the highlights over the weekend.

Outcomes vs. Process

Some years ago, I worked at a couple of companies (EMC Controls, Digitrol/ITP Systems) that were in the process control and factory automation business. They have both since gone out of business, or been absorbed into other corporate entities. I bring this up as a way to segue into the topic of this post -- process vs. outcomes.

These companies were in the business of supplying process control to industrial customers. What we controlled was process, and by controlling the process, we affected the outcome. There is no such thing as 'outcome' control. That's not to say that there are not outcomes -- it's just to point out that in order to achieve some outcome, you choose the outcome as your goal, and then control the process used to achieve the outcome. The more effectively you control the process, the more likely you are to hit the desired outcome.... presuming, of course that the chosen process itself is capable of producing the desired outcome.

Choosing outcomes is relatively easy. Choosing effective process is much more difficult. Controlling a process (usually via measurement of some process metrics), once defined, is generally easier than choosing and defining the process.

Jeff Phillips wrote on a related topic back in July. To generalize the problem: how to choose an effective process so you are most likely to achieve the desired outcome?

In software design, one of the more useful concepts to come out in recent years has been design patterns. Can the idea of design patterns be generalized to help choose or design a process? Doing a "web search" (because Google doesn't want googling to become a verb), turns up a link or two. 

You get what you measure

You get what you measure.

This is an old and faithful management commandment that in my experience is sound advice. As in most things, the devil is in the details.

When I was at UPS  (developing software for their Package Systems division), they had an alphabet soup of different activities that they imposed upon management with the purpose of improving communication between manager and employee. One was called 'Talk-Listen-Act', or TLA. Management was required to schedule 'TLA' meetings with their direct reports. A manager's performance appraisal included measurement of the percentage of their TLA's that they had completed within the review period. Because their TLA 'effectiveness' was closely measured, all the managers within the unit where I worked dutifully scheduled and performed TLA's with their staff.

There may have been some value in having TLA's with some problem members of the staff, but for most, it represented a waste of time for both the manager and the staff member. The best thing that would come of it was perhaps a 'free' (i.e. expensed) lunch for both manager and staff member.

The TLA originated within UPS's operations divisions where the management is white collar and the 'staff' consists of blue collar truck drivers. In that environment, special steps had to be taken in order for management to have any one-on-one face time with their drivers, since the drivers were always out of the office, delivering or picking up packages. In that environment, having some more formal mechanism to encourage communication between management and their direct reports makes sense.

In the environment of software development, where management and staff interact face to face on a daily basis, having the formalism of a TLA was (is?) not a good use of time.... yet, because 'you get what you measure', a lot of cycles were burned to satisfy the metric that its measurement demanded.

In small companies, where the distance between the work you perform and the company's bottom line is short, it's easy to know what you should measure. In large companies, where employees are far removed from the company's bottom line, company management must invent the metrics against which performance can be measured. The choice of metrics is often driven by internal politics, the 'need' to build empires in order to climb the corporate ladder, and/or other motivations that serve their manager advocates more than they serve the business. Because the choices don't obviously flow to the bottom line, it's often difficult to evaluate the utility of the chosen metrics.

In politics, things are similar to the problems faced in large bureaucratic corporations. Instead of playing to the internal audience of corporate players, politicians play to a larger audience. For policy wonks, because their success is measured by the ability to advocate policies that will get adopted vs. the ability to advocate policies that actually work, we witness politicians advocating feel-good programs that have little chance of producing the desired outcome. Because we measure good intentions, good intentions are what we get. It's a wonder that anything works.

You get what you measure -- So it's hugely important (and often very difficult) to measure the right thing.

Swarming behavior

Did you ever notice that cars on the highway seem to travel in packs? This observation hit me when I was southbound on the New Jersey Turnpike. I was a singleton car -- not in a pack, and then was passed by a pack of cars. After the pack passed, I was a singleton again. It was tempting to speed up and join the pack, which is a simple explanation of how car packs form.

I was attentive to this behavior at the time because I had recently read a couple of books on complexity. Complexity theory offers insights into a wide variety of problem domains, the formation of car packs being one of them....

But I spend a lot more time developing software than driving a car. Is there 'pack' behavior in the software development domain? The simple answer is an obvious 'yes'. Whether it's the methodology (e.g. Extreme Programming), the language (e.g. Ruby), the OS (e.g. Vista), etc. we all take shortcuts that put us in one pack or another.

From a business perspective, it's interesting to speculate on what rules must be followed by the pack members in order to create the pack and have it grow. In the flock of birds examples common in the complexity literature, the number of rules that each bird must follow in order to create a flock of birds is quite small.

What rules must prevail when creating a community (a.k.a. pack) to surround a particular methodology, or a particular programming language, or a particular product? Clearly, the one minimal rule is that community membership must confer some perceived benefit to the individual members that compose the community. In nature, we can see the survival value of a pack of wolves, or a herd of elephants. The value of swarming in lemmings is more difficult to understand.

What value is there in swarming/pack/community behavior within the software development domain?

History lesson

In my spare time, I've been working my way through a 4 volume history on the American colonial period and the American revolution. As I write, I'm into the 4th volume, and the revolution is under way.

I know it's cliche, but it's amazing how the patterns of political intrigue have remained constant over these many years. Sure, the names we attach to the good guys' and bads guys' philosophies have changed -- Whig, Tory, Liberal, Conservative, etc., but the patterns in politics are virtually invariant. Politics is a game of power, whether it's played in the boardroom, or in the public square.

QVCS-Enterprise pricing

QVCS-Enterprise prices will be going up with the 2.0 release on August 31. The new price will be $49 per concurrent client. The old price was $99/4 users -- or around $25/user. The other change in pricing is that beginning with 2.0, you'll be able to buy single user licenses -- so prices start at $49 instead of $99. A standard discount schedule will apply for volume purchases.

(A concurrent client is any user who must login to the server. This means that a single user who uses both IDE integration and the client application at the same time consumes 2 concurrent clients -- 1 for the IDE integration, and 1 for the client application, since each require a separate login to the server).

The justification for the price increase is increased and improved functionality (e.g. IDE integration). With IDE integration, QVCS-Enterprise offers close to the same functionality as QVCS-Pro, while providing better performance, much better support for remote users, and multi-platform support. The original $25/user pricing was meant to be an introductory price for a 1.x product. With 2.0, that introductory period is over -- With 2.0, the product is more mature, and still an incredible value at $49/concurrent client.

Of course, if you like the old pricing, you can still buy QVCS-Enterprise at those old prices through August 30. You'll get to upgrade to 2.0 'for free', since 2.0 will appear within 1 year of your original purchase.

Feature creep

Since I like writing code more than I like writing documentation (who would have guessed!), I added yet-another-feature to 2.0: the ability to choose an alternate location for reference files on the server.

In QVCS-Enterprise, if you enable the creation of reference files, by default, those reference files will be created in the qvcsProjectsReferenceCopies directory tree (beneath the server install directory). This new feature allows you to specify some alternate location for the reference files.

The feature is simple minded -- since the admin tool can run anywhere, it cannot verify that the string you enter for the directory name is valid (think running the admin tool from a Windows box, talking to a Linux server, or vice versa) -- that validation occurs on the server... If you enter a useful string, i.e. one that is valid, then things work like a charm. If you enter an invalid string, the server will reject it, and the requested change to the project's properties will be discarded.

Reference files (a.k.a shadow files), are just copies of the most recent default revision for the associated workfile. They're handy to have if you want to share your work product with folks who are not users of QVCS-Enterprise.

Updates galore

This past week, I've posted updates for both QVCS-Enterprise (1.2.13) and QVCS/QVCS-Pro (3.10.12).

Both of these updates are bug fix releases.

In the case of QVCS-Enterprise, the new build fixes a problem that shows up when you have users who have different ways of capitalizing the name of the same file. For example, if user A has a file named foobar.java and user B has a file named FooBar.java, QVCS-Enterprise will normally see these as different files. If, however, you have enabled the 'ignore case' project level setting, QVCS-Enterprise is supposed to treat them as if they were the same file. The 1.2.13 release makes it so it finally does treat them as the same file.

So why does QVCS-Enterprise even allow foobar.java and FooBar.java to be considered as separate files. The simple answer is that in *NIX environments, the file system treats foobar.java to be different than FooBar.java. Since QVCS-Enterprise is cross-platform, it should support this scenario. Admittedly, this should be the rare case, but in software, it's often the boundary cases that drive both requirements and design choices.

In the upcoming 2.0 QVCS-Enterprise release, new projects will have the 'ignore case' setting enabled by default. Note that with the current 1.2.13 release, if you change the 'ignore case' project setting, you'll need to restart the server in order for the change to take effect.

The 3.10.12 release of QVCS/QVCS-Pro is strictly a bug fix release -- it fixes a problem with the 'login as' feature.

You can get the bits for the latest stuff from here. 

QVCS-Enterprise 2.0.2 beta now available

I just posted the bits for the 2.0.2 beta.

It's not yet feature complete, but it's got the big feature for the 2.0 series of releases: support for IDE integration.

The documentation has been updated some, though I still have some work to do there. The cool change with the way the docs are provided is that the docs are now embedded within the server .jar file. The downside of this change is that users can't easily edit the web site that the server provides. The advantage of this approach is the guarantee that the link to the associated client .zip file is accurate.

There are several things that remain to be completed for the IDE integration. For example: addition of support for command options for the various actions that you can perform within the IDE. Suppose you want to apply a label to a file when you check it in -- that functionality isn't yet completely there.

If using IDE integration, the biggest thing to be wary of (that comes to mind): the transport is not secure. This means that if you want any kind of security, you'll need to connect via a VPN, or similar mechanism. You also need to use the client application to define the external visual compare utility that will be used within the IDE for visual compares.

Aside from the additions to IDE functionality, the rest of the work going into the production release of 2.0 will focus on usability improvements. I've got a pretty long list of TO-DO's in this area (not all of them will get done before the release) -- if you've got a suggestion that you'd like to see implemented in 2.0, now's a good time to let me know.

Java puzzler

There is a bug in QVCS-Enterprise 1.2.11 (and earlier releases) that only just came to light. You can get a little background from this forum thread.

The bug only shows up if you run your QVCS-Enterprise server on a Linux platform. The puzzler was to figure out why things were behaving differently on Linux than on Windows. I set up my Linux box as a server for remote debugging and spent some time tracking down the problem. As it turns out, the problem was caused by slightly different behavior on Linux.

The offending (a.k.a buggy) line of code looks like:

int descriptionLength = 1 + description.length());

where description is just an instance of a String object.

The bug-free (a.k.a fixed) line of code looks like:

int descriptionLength = 1 + description.getBytes().length;

This implies that on Linux at least description.length() != description.getBytes().length.

This is a surprising result, at least to me. I had thought that the length of a String would be the same as the length of a String's byte[]. As the above code shows, and the Linux JVM confirms, this is not universally true. It's probably documented somewhere, and it probably has something to do with different internal String representations on the respective platforms. In any case, it's the kind of subtle bug that demonstrates the Java mantra of "write once, test everywhere".

This is okay. In my experience in using Java across platforms, almost always, deploying on a different platform helps expose bugs in your own code instead of exposing bugs in the JVM.

I'll be publishing a fix for this bug later this week. If you need the fix immediately, a patch is available.

Back from a Canada vacation

We just finished up a vacation to Canada. Our primary destinations were Montreal and Quebec city. We had a good time in both.

Montreal is a big city -- 1.5 million or so. They have a good subway system, and the old city where we stayed is very walkable. While I remember only a little of my high school French, it was little needed: it was easy enough to figure things out, and the folks at restaurants and hotels all spoke good English and were friendly and helpful.

In Montreal, we stayed in a loft apartment that was part of a hotel, in the old part of the city. We were within easy walking distance of the St. Lawrence river, City Hall, the Metro, and countless numbers of restaurants and shops. We left our car at the hotel the whole 4 days we were in town -- preferring to walk and/or use the Metro as the way to get around.

While in Montreal, we caught the first of a series of fireworks displays (Montreal hosts this annual international competition) -- the one we saw was put on by the Swiss. We had purchased good seats, figuring it would be unlikely that we'd ever be back to see the fireworks again. Most impressive. The show lasted a little over 30 minutes, and was finely choreographed to synchronize with each song that they played over the sound system. The weather was pleasantly cool, and the fireworks were worth seeing again.

In Quebec city, we also stayed in the old part of the city. Everything was within easy walking distance: There was a convenience store two doors up the street; the river was only blocks away, and the shopping tourist section was also just a short walk. On St. Louis street, (less than a block from our apartment), there were endless restaurants, many with outdoor seating. I'm not Catholic, so I don't know how many saints there are. It's a good thing there are lots, though, since most of the streets in old Quebec are named after some saint or other.

The old part of Quebec seems a little cleaner than the part of Montreal where we stayed. Both were generally cleaner than most American cities. The streets felt safe. In Quebec, there were lots of student tour groups trooping through the old part of the city... apparently on 'educational' field trips -- you know the kind they schedule at the end of the school year so that teachers can pretend to teach the restless students, and the restless students can pretend to learn.

I had feared that we might need more knowlege of French in Quebec city. The fear was unfounded. English is a second language, but widely spoken, and everyone was very friendly and helpful.

We'll have to make the trip again -- maybe in the Fall some year.

Open Source Java

Eric Sink had a recent article where he spills some bits on Java, and Sun's recent tentative steps to take Java Open Source. The article generated a number of comments, many along the lines of how slow Java is, and what a lousy language it is, etc.

By most measures, Java has been an incredible success. It was so successful that Microsoft tried (and failed) to gain greater control of it. There is no doubt that it could be even more successful, but that observation applies to almost everything.

I work with both Java and C++ on a daily basis. Both languages are good. If I had to choose between Java and C++ strictly for productivity, I would choose Java 90 percent of the time: Java is a simpler language, has built-in garbage collection, and has a much better built-in collection of libraries than C++. Java performance these days is quite good. There are a number of free Java development tools that rival Microsoft's Visual Studio (NetBeans and Eclipse come to mind) that are written in Java.

(Readers should not infer from this that Quma will be abandoning the C++ based QVCS and QVCS-Pro products!!).

What I don't get about Eric's post is his pose of omniscience. He admits that he doesn't use Java, and then goes on to condemn Sun's business decisions related to that product. Sun made a decision seven years ago that they would not Open Source Java. The world has changed in the past seven years, and they have now reconsidered that decision.

Would Java have been a greater success had it been Open Sourced seven years ago? Will Java now be more or less successful as a result of the move to Open Source?

I don't know the answer to either question... and neither does Eric.

Echo chambers and the downside of virtual communities

I used to be interested in politics. I'm still interested in the topic in a more general way -- sort of a meta-politics, but these days, I'm not as easily distracted by the day-to-day hurly burly that the inside-the-beltway crowd thrives on. Part of the reason I'm less interested is that I'm now old enough to recognize that many of the strategems that are played by both sides are just a reprise (in some form or other) of the past. Also, neither major party is saying anything that is interesting. And finally, I've realized that there are so many more ways to spend my time than wandering in the ghetto that American politics has become.

Before the Republicans gained control of the House of Reps (1994), they were known as the 'Stupid' party, and the Democrats were known as the 'Evil' party. Now that the Republicans have been in power, the roles have reversed -- the Republicans are now the 'Evil' party, and the Democrats are the 'Stupid' party. This isn't to suggest that either side has the lock on stupidity or 'evil' behavior. There seems to be plenty of both in both parties. Neither party can truthfully claim some moral high ground -- they have both been corrupted by the power inherent to the offices they occupy.

This may sound like the observations of a cynic -- and I confess I'm sometimes comfortable with that label. But I also like to think that I have my eyes open, and am just trying to avoid making the same mistakes that I've already made.

On a separate, and only slightly related topic, there's another meta-type what-if that I recently thought of. In the so-called halcyon days of the 1950's- early 1960's we lived in an age that was unique in the sense that we had just a few major media outlets. As a result, the public dialog was defined and framed by the editors/producers of the major network evening news programs.

These days, the public dialog is no longer dominated by anyone -- whatever your viewpoint, you can find some media authority to supply verification of your own prejudices. The what-if part of this observation is this: isn't this more like what our country (and indeed the world) was like before we had mass communication? In those olden days (say the 1800's), a citizen's exposure to the wide world was limited. What you saw most closely was what was going on in your own community. Anything you learned about the wide world had a time delay built in, and was filtered and distorted by having traveled through many 'hands' before being consumed.

In today's media environment, you can safely 'live' in your own virtual community, and consume only the distorted and filtered view of the world that is supplied by your virtual community's echo chamber.

This analogy may not survive close scrutiny, but it has some merit, if only to make the observation that the Internet makes it much easier to find fellow-travelers. The downside of this is that most people prefer to stay in their own communities and in their own comfort zones, and so never really get to know the folks on the other side of some virtual divide. And just like in the olden days, where country bumpkins hadn't a clue about life outside their little world (and city slickers had no idea of what life was like on the farm), we're creating a world where it's becoming easier and easier to ignore viewpoints with which we disagree.

Early bird special; MFC CSocket advice

I just uploaded the likely bits for the upcoming 3.10.7 release. The official release date is this Friday; but you can get the bits early here. I say likely, because I don't expect to make any additional changes to the code between now and Friday -- unless there are some late bug reports.

Things have been quiet on the blog because I've been preoccupied -- coding away on both the 3.10.7 release and the 2.0.x Enterprise release. As noted above, the bits for 3.10.7 are now stable. 2.0.x Enterprise is a completely different story.

The big feature for 2.0.x Enterprise is be the addition of support for Microsoft SCC IDE integration (like QVCS-Pro). To implement this, I've been writing the IDE client piece in C++, and making the corresponding transport changes in Java for the server code. Along the way, I implemented socket code on the client to communicate with the server, just like the existing Java client. One of the twists that requires server changes is that I can't use Java Serialization on the C++ side for object serialization, since I don't have a JVM on the client. This means writing a serialization layer on both server and client to push the bits back and forth. The result is a better use of bandwidth, at the expense of writing and maintaining the serialization code.

Since QVCS and QVCS-Pro are MFC based C++ applications, I figured I'd write the client SCC .dll as an MFC based .dll Since I had to do socket communications between the MFC C++ client and the Java server, I figured I'd use an MFC supplied socket class. As it turns out, that was a mistake that cost me several days of frustration: I tried to use the MFC CSocket class, since it seemed to be a closer fit to what I needed. For whatever reason -- it was not a good use of my time to try to debug what was going on -- the CSocket class really did not fit the threading model that I needed to support. There must be some scenarios where CSocket can work, but it was not reliable at all in the way that I was trying to use it. The Microsoft docs were not helpful in pointing out the limitations of the CSocket class -- for that I had to rely on dribs and drabs of complaints that I found via Google search.

In the end, I punted, and wrote my own socket class that wraps the Windows socket API's, based on some sample code I found on the Internet. It works well, and is actually very simple. My guess is that almost everyone else who has to write socket code in an MFC environment goes through a similar two days of agony, and then does the same thing that I did. The result is more reliable with well defined behavior than the MFC supplied alternatives.

The bottom line advice -- if you are thinking of using the MFC CSocket class for anything useful, think again.

Web site migration

qumasoft.com now has a new home. I'm still hosted on Verio, but I switched hosting plans so that outbound mail from qumasoft.com will have a much lower chance of being treated as SPAM.

Hopefully, this migration has been pretty transparent, but if there seem to be any hiccups, please let me know. (e-mail is now working as expected).

Usability, Usability, Usability

I just got off the phone with a QVCS user. He was having problems getting a new project defined. The basic problem was that he was failing to fill in the access list on one of the new project wizard pages. This is something that has been in the product for a long time, but it got me to thinking: what if lots of prospective users run into the same problem, and just give up, thinking that the program is broken? There are probably a number of other usability land mines out there that I'm blissfully unaware of.

This is no small problem. Back when I worked at UPS , we invested a lot of time and money in usability studies for the UPS OnLine product (I'm not sure what UPS calls the product these days, but it is a Windows application that UPS provides 'for free' to their lower volume customers that allows them to print shipping labels, track packages, and send electronic manifests to UPS for both tracking and billing purposes).

Quma lacks the resources of a UPS, so I have to rely on user reports and my own judgement when it comes to usability. The problem with defining the access list is clearly not a user error, but a usability problem: the program should make it more obvious what action the user is required to perform. How many other usability 'gotchas' are there that turn users away? I'm listening.

Holiday Distractions

The holidays generate many distractions. The distractions are the kind that make the holidays a happy time:

• picked my daughter up from college...
• went to visit my son and his fiance -- he's on his own, and has been now for close to 2 years.
• shopping
• "must see" movies (Pride and Prejudice)
• peppermint ice cream...

Between the distractions, I've been working on cleaning up some bugs in QVCS 3.9.23, and some bugs in Enterprise 1.2.10. Both will get refresh/bug fix releases near year end.

The 3.9.23 bugs are subtle, and not urgent (which is why they haven't been fixed already). One area of cleanup surrounds the correct treatment of obsolete files. In QVCS, an obsolete file is one that cannot be changed (it's obsolete), but is available for 'get by label' operations for those cases where you need to get an old revision for building an old release (for example). The goal of the changes is to make the handling of obsolete files more transparent than is currently the case. Along the way, I've had to cleanup some subtle problems with the file rename operation. The last of those changes went in today. Thanks to David A. for reporting a weird boundary case that turned out to be related to the rename operation.

This next QVCS/QVCS-Pro build will also add support for two new keywords suggested in this forum topic. 

The Enterprise changes are also minor: In some rare cases, the server shutdown doesn't happen in a clean way leading to corruption of the role store and/or the authentication store. The symptoms are the sudden disappearance of projects and/or the sudden disappearance of users. The bug is very difficult to reproduce, but the changes for the next build should address the issue. The next build will also include support for the same 2 new keywords mentioned above for QVCS/QVCS-Pro.

Web site updates

If you've been paying attention, you may have noticed recent changes to the Quma web site. The changes were made as a result of suggestions from Al Harberg. Al's business is PR and PR related areas. He offers a very reasonable service where he will review your web site, and provide a useful critique. I'm more of a propeller head than a sales guy, and can use any help I can get in the sales area. Al's suggestions helped add a little more sales pitch to the site. I haven't asked Al for his comments on the changes yet, since I want to get more comfortable with them myself. The measure of success will be an increase in sales.

In any case, I think Al did a fine job. Whether my execution of his suggestions bears any fruit remains to be seen.

Knowledge Problem II Reprise

As it relates to software development, the knowledge problem is a double edged sword -- a methodology will succeed to the degree it provides tools to solve the knowledge problem. But solving the knowledge problem is not so simple as making it easy for everyone to know everything. A methodology must also provide effective tools for information hiding -- for making it so that the information that is available to be shared is only the relevant information -- not a cacophony of detail.

Knowing where to draw the boundaries in system design is difficult. From the knowledge problem perspective, the boundaries effectively determine what information needs to be shared, and what information can be hidden. If you draw the boundaries right, you can create something beautiful. Draw the boundaries wrong, and you'll get a pile of sludge.

So far, the only way to learn how to draw these boundaries is to get in the trenches and create systems -- some will work, and some will not. It's the kind of skill that is best acquired by doing. Reading books on this methodology or that can help give you a vocabulary for dealing with the problems of abstraction, etc. But they cannot teach you the lessons that you'll learn by actually building things.

The Knowledge Problem II

In March, I wrote on  the problem of sharing information amongst team members. As I tried to note there, it's not a problem that's unique to software development. Many people suffer from a delusion that they can know more about something than it's actually possible for them to know.

The durability and recurrence of these delusions are evidence of our human desire (weakness?) to believe things that cannot be true. The knowledge problem exists, and yet we again and again, ignore or deny it -- almost like we can't help it.

What got me back on this topic was a recent article in Atlantic Monthly about the belief in God. Very briefly, the article proposes that humans are hard-wired to believe in God -- that it's a side effect of some of the social behaviors we acquired on the way up the evolutionary ladder. The generalization of this observation ties in with the observations above about peoples' tendency to believe things that cannot be true.

In religion, wanting to believe -- faith -- is sufficient. Within the domain of software development, faith doesn't push the bits out the door... and yet, the tendency to believe in things that cannot possibly be true is no more evident than in the adoption of the latest methodology as the way to solve the business imperitive to produce a higher quality product in a shorter period of time.

Damon Poole writes about the buzz around Extreme Programming (XP). He brings some good comments to the discussion. I don't mean to pick on Extreme Programming here. I'm just using it as an example because it is one of the newer methodologies that offers to solve the software development problem.

Does XP make the knowledge problem go away? No. Ergo, we must be careful not to believe something that cannot be true, as appealing as some of its tenents may be. Knowledge of a problem is scarce; genuine understanding of a problem is also scarce. If a methodology removes that scarcity of knowledge and/or the scarcity of understanding, then it has a chance of delivering improvements.

I don't want to take the space here to debate the merits of each and every XP practice. My goal is to point out that XP succeeds or fails based on its ability to attack the knowledge problem.... oh, and just because we want to believe that something works... well you get the idea.

Release mania

Eric Sink (a founder at competitor SourceGear) has an interesting post about a recent flurry of product releases that they went through for their Vault product. He supplies a lot of background. Kudos to him for providing a story that almost any software firm can relate to. Here, at Quma Software, I went through a similar recent spate of releases, and while the nuts and bolts of the details are different, the general theme of the story is the same. To quote:

The six billion people of the world can be divided into two groups:

1. People who know why every good software company ships products with known bugs.
2. People who don't.

Those of us in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group 2, perhaps a new hire on the team or even a customer. They are shocked that any software company would ever ship a product before every last bug is fixed.

Here in the real world, products have bugs, and we fix them as we can, based on their severity, how easy they are to fix without breaking something else, and other factors. The goal is always to create a product that is better for our customers.

One factor that I don't remember Eric discussing (he may have -- it's a long article), is the degree to which customers are exhausted by release churn. I know that as a customer of other tool vendors, I don't like the time it takes to install a new release, and I especially don't like release churn.

In QVCS land, updates are easy enough to perform, but I'm sure that there are users who forego performing an update because they perceive it to be a nuisance.... and frankly, if you have more than one release a week, it is a nuisance. But better to get a fix out to the user community immediately, even if it's embarrassing, than to pretend that the software has no bugs.

UPDATE: Added a style wrapper around Eric's quote to make the quote boundaries more readable.

QVCS/QVCS-Pro and Windows 98/Me

Beginning with the 3.8 release, QVCS/QVCS-Pro no longer worked on Windows 98 or Windows Me. I never took the time to understand why. As it turns out, the reasons are simple, and a naive trust in Microsoft is partly to blame.

Beginning with the 3.8 release, I began to use the Windows API function called InitializeCriticalSectionAndSpinCount(). Its purpose is to initialize a critical section blob that can later be used as a semaphore to serialize access to a shared resource. It turns out that Microsoft changed the signature (read behavior) of this function between the Windows 98/Me platforms and the later releases of Windows (e.g. XP and W2K).

For XP and W2K, this function returns a nonzero value on success, and a value of zero on failure. However in Windows 98 and Me, the function does not return a value at all, but throws an exception on failure. As a consequence, if you write code that actually checks whether the function call succeeds, you cannot use the same code on XP and W2K as you use when running on 98 or Me. This was the fundamental issue that caused QVCS to fail to start on 98 and Me platforms.

I suppose shame on me for not reading the function documentation more carefully, and for ignoring the 98 and Me user. I'll offer the excuse however that it has been Microsoft's practice in the past to rename functions that actually change behavior -- maybe to InitializeCriticalSectionAndSpinCountEx(). Would it have been too much to expect that they change the name of the function to reflect that difference in behavior?

In any case, the 3.9.22 build has wrapper code around the use of that function call so that it behaves as needed, depending upon whether the code is running on 98/Me or whether it's running on XP/W2K, etc.

Bottom line: if you are still using Windows 98 or Windows Me, you'll need the 3.9.22 build in order to get things to work.

How big is your... QVCS Project

I've put a poll up on the forum site here. Please take a look, and vote. I'd like to get a read of the typical QVCS project size.

The poll is prompted by a support thread  on the forum where the user is wondering why QWin takes so long to start. I'm not confident that we've gotten to the bottom of what's going on, but along the way, I learned that the user had close to 10,000 files in the project, and that one directory had over 4,000 files.

QVCS can handle projects that large, but startup will be slow, especially if the cache files haven't been built yet. Also, there's added work in computing the digest values for the workfiles. This all adds up to a slow startup time for a large project. Once the cache files have been built (a one time thing), and the digest values have been computed (a one time thing), then subsequent startups should be faster -- provided things haven't changed since the last startup. By that I mean, that if QWin detects that a workfile has changed since its digest was last computed, it will re-compute the digest for that workfile.

In any case, please take the poll.

Search now available

I just added the ability to search the Quma web site to the Quma home page. I'm using the free picoSearch service. It's very easy to add to the site. Whether it's actually useful, or gets used we'll have to wait and see.

Newsletters now available on the web site

I just finished adding the QVCS newsletter to the web site. If you already subscribe to the newsletter, these online versions are handy alternatives to hanging on to the newsletter e-mail. If you don't yet subscribe to the newsletter e-mail, you can get a taste of what you're missing here.

SPAM from qumasoft?

Some agressive SPAM filters take it upon themselves to decide that e-mail from the qumasoft.com domain is SPAM. I note this for a couple of reasons.

I don't send SPAM. I do publish the newsletter once a month, but that's to a fully opt-in list... and that's the only bulk e-mail that originates from the qumasoft.com domain. There are spammers out there who hijack the qumasoft.com domain in their fake e-mail header so that lazy SPAM filters will erroneously conclude that the e-mail originated from qumasoft.com. The bottom line is that there are some folks out there to whom I cannot send e-mail from qumasoft.com.

This is a nuisance, since I have to use an alternate e-mail account for that correspondance. As a result, that correspondance doesn't get filed properly. In addition, since I don't monitor those e-mail accounts with anywhere near the regularity that I monitor the qumasoft.com accounts, folks think that I may be ignoring them.

If you send e-mail to me, and haven't gotten a response, this may be the reason. In almost all cases, I'll respond to e-mail within 24 hours. If you haven't received a reply within that timeframe, please check to see that your SPAM filter is not blocking the qumasoft.com domain.

UPDATE: One other thing -- if you send me e-mail without "QVCS" included somewhere in the subject line, or without "QVCS" included somewhere in the body of the e-mail, the e-mail will likely go into my own junk mail folder, and get treated here as SPAM. When sending me any kind of correspondance, please put include "QVCS" in the subject line.

Stumble Upon

My brother pointed me to a fun surfing plugin called Stumble Upon. You can read the pitch yourself. It's a great way to take a break from work. Some of the non-technical sites that I've discovered as a result:

Squashed Philosophers -- a sort of Cliff's Notes condensation of all the great philosophers.

Pictures of Pennies  -- an collection of pictures of what some undergraduate civil engineering student did with stacks of pennies.

Hurricane Wilma

Hurricane Wilma knocked out power at the hosting site for qumasoft.com. Obviously (you're reading this), things are now back on-line. Verio (Quma's hosting provider) has some facilities in Boca Raton, Florida. They lost power mid-morning yesterday, and only got things restored earlier this morning. I'm not happy about the outage, but I guess I can understand the problems of having a category 2 hurricane pass directly over your location. They are currently running on backup generators, so things remain a little fragile. Hopefully, utility power will be restored before they run out of fuel.

Back from Hawaii

We're back from a 3 week Hawaiian vacation. I'm happy to be back, but not as happy as I thought I might be. Hawaii is nice... but you eventually run out of the capacity to appreciate the wonders of a tropical paradise.

I'm not enough the world traveler to know how Hawaii compares with other tropical destinations, but for us, it's a good fit, and a pleasant diversion.

We visited the 4 main islands. First Oahu, then Kuaui, the Big Island (Hawaii), and finished up on Maui. Each island has its own distinct character, so to recommend one over the other is difficult because it depends on what kind of experience you're going for.

In any case, Quma efforts were on the back burner during the trip. I was able to keep up with e-mail, thanks to staying in places that had Internet access, and when that wasn't available, falling back to the use of my Verizon wireless data card -- which worked great.

All our flights were on time, and we never lost luggage. Budget car rentals worked well for us; I cannot recommend Alamo -- it took over an hour to get our car on Maui.

Gas prices are much higher than here in Maryland. In Hana (on Maui), we paid $4.20/gallon, elsewhere we paid from $3.20 to $3.79/gallon. Prices here are around $2.80/gallon.

Mobility

Got back yesterday from a weekend trip to Winston-Salem, NC for our 30th college reunion/homecoming. In preparation for the trip, I had dumped my DSL account with Verizon, and signed up for the Verizon Wireless 'all you can eat' wireless data plan. The idea being that I'd be Internet connected, even if our hotel was not.

It worked out pretty well. The hotel (which was nice enough), claimed to have both Wi-Fi and hardline Ethernet connections. Neither worked, so I fell back to using my new WAN wireless card. The card is an AudioVox 5740. While the speed was not anywhere as fast as the cable modem that we have here at the office, it worked well enough. On the drive back to Baltimore, I tried out true mobility by trying to connect to the Internet while the car was traveling at highway speeds. It worked well, providing better speed than I saw from the hotel. Pretty cool. Now the 'office' is where ever I take the laptop.

Laptop recovery

My laptop hard drive died yesterday. RIP. This Toshiba 5205-S503 laptop has otherwise been pretty reliable.

I replaced it with an 80 gig drive (it was a 40 gig drive), and have been spending the better part of a day and a half piecing things back together so that I can take Quma 'on the road' when I want.

About the only thing good to say about a hard drive failure is that it allows you to get rid of cruft that you genuinely don't need.

My laptop is now faster than it's been for quite awhile. Who can say what was slowing it down, but whatever it was is now encased in a useless 2 1/2 inch hard drive that is sitting on my desk, waiting for a more permanent disposal location.

Patching things back together also helps inform me about the utility and completeness of my backup strategies. Nothing important was lost -- all source code, all customer database info, all e-mail, etc. survived through luck and process.

Of the software I had to put back together, most was relatively painless. Installing Windows XP from the recovery CD's was an interesting and lengthy exercise. After it reformatted the entire drive, the install went smoothly. It then took 2 or 3 'fetch updates/reboot' cycles to get all the latest patches from the Microsoft site. Reinstalling Norton Anti-Virus was not so easy. Symantec's purchase process has always sucked, and their download recovery process sucks as well. I continue to use their products because I'm familiar and comfortable with them. I've also use MacAfee, and found that it sucked even more that NAV. In contrast, Zone Alarm was a piece of cake.

In any case, things are close to back to normal. I don't think I lost anything, but if you had sent me e-mail recently and didn't receive a reply, then the disk crash is the likely reason -- that's my story and I'm sticking to it!

LinkedIn.com - an interesting site

I just joined LinkedIn.com. It's a sort of high tech approach to manage and encourage networking.... as in the people kind of networking. It's an opt-in, kind of service that has several different levels of service. I joined at the invitation of Gregg Smith, a former boss at TeleCommunications Systems  (where I used to work before going at Quma full-time). The concept is interesting, and definitely attractive to the business development (BD) type folks, and it's painless enough even for geeks like me to use it. The web site is like an actual implementation of the 6-degrees of separation from Kevin Bacon  meme, where the site shows you how many different people are networked to you by virtue of the immediate connections that you personally have. Because Gregg is a very successful BD kinda guy, I've got over 900 people (out to 3 degrees of separation) that I can get to. The site provides for search and introduction services. I'm not sure whether anything will come of my connections, but its fun to see how many people I could get to know by virtue of the people that I know.

Stating the obvious in fewer words than Joel Spolsky

Tom Warfield points to what he claims is a 'must read' post by Joel Spolsky. Don't trust Tom's judgement on this one. Joel spends a lot of bytes stating the obvious:

1. Some developers are better than others.
2. It makes sense to hire the good developers and not hire the mediocre ones.
3. Some of the really good developers can create things that the average developers will never, ever, ever, be able to create.
4. It makes sense to pay the really, really good developers lots of money (and keep/make them happy) because they are able to produce 10 times as much as an average developer (if the average developer can even produce it at all).
5. Management outside of the software development domain generally doesn't understand any of the above.

This doesn't seem like a huge insight to me.... maybe I'm just getting too old.

UPDATE: Added (and keep/make them happy) to #4 as that is one of the key elements of Joel's approach to running his business.

SIC Impressions

I'm back from Denver where I attended the Shareware Industry Conference. It was my first SIC. I suspect it won't be my last.

Microsoft attended this year, which was a good thing. They were attentive and humble. They were giving away copies of their Beta2 of Visual Studio 2005. I got a copy, though I'm not sure if I'll have much time to take a good look at it. They hosted a session where they described their Shareware Starter Kit -- a kind of embedded software registration toolset that has the goal of making it easier to build product activation and registration behavior into your application. They initially support C# and VB, and will soon have support for C++. They got hammered pretty badly on the size of the .Net runtime. On Saturday, they hosted a session on Visual Studio 2005. It was mostly a demo session for VS 2005 -- it has a lot of cool features. I especially liked the refactoring features which were quite complete. Microsoft was ably represented by Michael Lehman and Dan Fernandez. They both have blogged about the event.

The SIC is also discussed here.

As a newby to the conference, I took some time to just get a feel for the goings on. Most of the sessions were business focused, which was a good thing. I did get a chance to have a few one-on-one conversations with fellow attendees.I would usually try to ask: what do you use for version control. I was initially surprised when most responded with "None". As I thought about this, it began to make sense. Many of my fellow shareware authors came to their respective businesses not from a background in software development, but from a background in some other area of business. This other experience gave them the domain knowledge they needed to create their shareware product, but it did not magically translate into knowlege about software development best practices. In a sense, it's a largely irrelevant point. Those authors who are most successful make a pretty even split of their time between sales/marketing and development work.
While I'm sure using version control would make them more effective developers, only half their time is spent on development. Since I spend much more of my time on the development side, it's a much more important tool for me.

SIC in Denver

I'm off to the Shareware Industry Conference in Denver. It's a 3 day conference. Attendance in the past has run around 300 or so. I'm curious to see whether it will be worth my time (and money) or not.

Back from South Dakota...

Back from the Black Hills of South Dakota. We rented a house out there for the week, near Rapid City, and did the standard sight-seeing trips for the area: The Badlands, Crazy Horse, Devil's Tower, Sturgis, and Mt. Rushmore. This site is a good place to start. The house had high speed internet, so I was able to get e-mail, process orders, monitor the QVCS forums, etc.... pretty convenient.

I also had time to read several books, and start on the sequel to Dan Simmons' Ilium: Olympos.

The Black Hills is a beautiful area, and not so crowded with tourists as some of the other popular destinations 'out west'. We'll have to go back in another 10 years to see what progress they've made on the Crazy Horse Memorial.

I didn't get anything done on QVCS at all -- but that's the whole point of taking a vacation. It's good to be back home.

Here's some pictures I took with our relatively new digital camera (a Sony DSC-P100). I haven't completely figured out how to use it, so the sky is washed out some times... pilot error.

MIT Blog survey

> I just filled out the blog survey that MIT is running. With millions of blogs out there, I guess someone can become a professional blog analyst. As TLA's (three-letter-acronyms) go, I guess PBA isn't too bad. If you run your own blog, they're interested in your participation.

Batman Begins

Two Thumbs Up. I took the afternoon off yesterday to see Batman Begins, and thoroughly enjoyed it. You can read real reviews elsewhere. The local movie critic at the Baltimore Sun claimed the movie was 'too dark', or something. Well his costume is black, and he is known as the 'Dark Knight'.... what did he expect? Kudos to all involved for making the movie of the summer (so far)... The previews for War of the Worlds looked good...

Marketing/Sales Projection Magic

One of the challenges in running a business (any business) is projecting future sales. The exercise has a tremendous impact on staffing decisions, product decisions, and a whole host of other aspects of the business.

While Quma Software is a one-man-band, I face the same challenge in projecting (guessing?) what QVCS sales will be. So far, the simplest approach has been to look at sales history, and plan that future sales will be around the same, allowing for some variation from month to month. Will the new release goose QVCS sales? That's the hope... that's the plan... but the reality is that I do not have a clue. Whether sales go up or go down is a decision that is in the hands of my customers.

The point of making this observation is not to state the obvious -- though it is perhaps obvious only to those people who are actually responsible for sales, but to point out the huge difference in the level of risk between someone who runs a business versus someone who works for wages. I've been in both roles. In my role as a 'for wage' employee, I never fully appreciated the distinction. Now I do.

Neal Stephenson's Baroque Cycle

I did finally finish Neal Stephenson's The Baroque Cycle several months ago. I had planned on writing a brief review, but won't bother, as it has been reviewed in many other places.

It's the kind of book that I really enjoyed, yet it's not the kind of book that I can recommend without reservation to anyone -- not because it's not worth reading, but because not everyone would enjoy the kind of book that it is. I read all three volumes over the span of probably close to a full year, maybe even longer, and each volume I read slowly, no more than maybe 20 pages a day, tops. This for me was a good pace. I'll be curious as the years roll by whether the reputation of this 2500 page trilogy endures, or fades. It certainly has the ambition to be literature, but history is the judge of that.

The greatest wonder to me in the books is that someone can write them. Truly wonderful.

Organizational Maturity

I've been thinking about organizational maturity and the building of institutions, etc. In a way, the ideas are all along the lines of complexity theory (for lack of a better word). The basic observation also dovetails in with CMM maturity models.

In the same way that you can grade a development organization to have a specific CMM grade (e.g. level 2 or 3, etc.), all organizations can be graded to have a certain level of maturity.

So, for example, if you have a corporation, it too has a level of maturity. This level of maturity results from a number of factors, and also determines the ability of that organization to execute on plans that the organization's management adopts. For a management team to be most effective, it needs to understand the level of 'maturity' that its organization possesses. Just like in software development, if management tries to execute on a plan that the organization is not equipped to handle (i.e. is not 'mature' enough), then the execution of the plan is guaranteed to fail.

Note that I've begun putting 'maturity' in quotes. Just because an organization is not 'mature' does not mean that the organization cannot be effective. It just means that there are some kinds of things that the organization will not be able to do.

If a management team wants to task the organization with executing on a plan that is beyond the reach of the current organization's 'maturity', then the most durable way for the organization to become successful is for it to first improve the organization maturity.

This really is just a generalization of the CMM model to areas beyond software development.

What contributes to the maturity of an organization? Part of that is beyond the direct control of the organization. The organization exists within an environment. Perhaps more than anything, the stability of the niche within that environment affects that ability of the organization to become 'mature'. If the niche is not stable, then the organization that services that niche cannot become stable enough to become 'mature'.

To step back a moment, I'd like to define what 'mature' really means here. What's really going on with maturity is the ability of an organization to create and maintain processes and infrastruture in support of the niche that they serve. With a 'mature' organization, the processes and infrastructure can become quite complex because the bandwidth of the organization's participants does not need to be consumed with figuring out how to provide the services that the market demands. That problem was worked out long ago, and has been internalized into the processes and structure of the mature organization. In mature organizations, the processes within the organization are mature (meaning old), durable, and the relationships among the organization's participants are also mature so that the communication time spent within the organization can be devoted to executing the processes, instead of getting to know the other players, figuring out how to solve the problem, inventing processes, etc.

In a sense, this turns the CMM model and organizational maturity on its head because it concludes that you cannot succeed in adopting or creating a mature organization if the consumer of your work product is a moving target.

Oh, wait. Maybe that's just a round-about explanation of why requirements churn always leads to project failure.

QVCS/QVCS-Pro Refactoring Update

The QVCS/QVCS-Pro refactoring blitz is beginning to wind down. It still have a few items to get to, but I've now switched over to the refactored code myself, and all is working as expected.

As I've noted here and on the forums, I'll definitely be doing a beta for this release. The likely window for the beta is the month of May.

SIC Conference in Denver

I'll be headed to the Shareware Industry Conference in Denver in July. This will be the first time that I've had the time to attend. Denver is a nice town -- I've been there many times on business and a few times for pleasure. I got a great deal on air fare: only $255 round trip from Baltimore on American via Orbitz. Hope they're still in business by July.

Is there a limit to intelligence?

Suppose the Einstein was the smartest human to ever have lived? I'm not suggesting that he was, but just asking the question rhetorically. Alternately, if we ask the question: If we can find the smartest person in the world, how come there isn't anyone smarter than that? And when we find the person who is smarter (more intelligent, whatever that means) why can't we find someone who is even smarter? Won't we at some point reach some kind of limit where we can't find anyone smarter than the smartest person we can find. Once we've found the smartest person, let's ask the question: why can't we find anyone smarter than that? Is there some inherent limit to human intelligence? Is there some overall limit to the thing that we call intelligence, irrespective of its means of implementation?

My hypothesis is that there is a limit, both to human intelligence, and to the overall category of intelligence, whatever its means of implementation. By this 'means of implementation', I'm proposing that there is also a limit to non-human intelligence -- that there is a kind of ceiling to intelligence. I don't know what the ceiling is, or how close we are to it in the general population, but my hypothesis is simply that there is a limit of some kind.

I did a bit of searching via google to see if I could turn up any links on this, and only came up with: Limits of Artificial Intelligence

This is something that should be covered more extensively, somewhere. Where?

The Causality Trap

Suppose there is a chain of events where event b follows event a. Does that mean that event a causes event b? There are some (many?) cases where the unwarranted inference is made that because b follows a, that therefore somehow a causes b. Correlation is not causation. What goes on in these kinds of fallacies is that along with a and b, there are a gazillion other variables that are part of the stew. What relation these other variables have with respect to a and/or b is ignored, either from genuine ignorance, convenience, sloth, or intellectual dishonesty. I've come to call this kind of mistake a 'causality trap'. It is a fallacy to invoke 'cause and effect' as an analytical method when there are unobserved and/or uncontrolled variables.

A prominent example of a causality trap is the daily reporting on the 'causes' of movements in the stock market. "The market went up today on news of blah, blah, blah." or, "The market went down today after Company X reported lower than expected earnings." Here's a tip: there's a whole lot more going on in the movement of the stock markets than can be summarized in a 10 second sound bite.

I don't mean to deny the law of causality. The problem is that people invoke the law of causality when it is not appropriate.

Another gem that I put in the 'Causality Trap' bucket is the Butterfly Effect (also here) example that is used so prominently when discussing Chaos Theory. The part of the Butterfly Effect that I find a stretch is the implicit assumption that somehow the system remains unperturbed by other larger effects after the initial conditions have been established. The equations that are used to create the beautiful variations in the Chaos Theory domain rarely describe any other stimuli that may affect the system after time zero. In the real world, this is a completely fanciful situation. A butterfly may flap its wings in Brazil, but there are a whole lot more important things that happen after that that will determine whether there is a tornado in Texas. To claim that the butterfly 'caused' a Texas tornado is to fall victim to a 'Causality Trap'. Who's to say that it wasn't some fishing boat in the Gulf of Mexico, or perhaps the guy growing coffee in Columbia? Or better still, perhaps the radiance of the sun had something to do with it? Causality requires that if you remove the cause, then the effect necessarily also goes away, every single time. If we kill all the butterflys in Brazil, will there never be another tornado in Texas?

I think by nature, we have an innate attraction to cause-effect explanations. (A self-referential assertion!). It's a way of taking a shortcut when thinking about very difficult problems. Rather than confess that we don't understand something, we invent a pat cause-effect explanation that allows us to pull the problem back into our comfort zone.

The Knowledge Problem I

In software development, there have been fads of one sort or other that spring up every several years that promise to solve the software development bottleneck. There then are usually a number of books published associated with the fad, and along with the books come training courses, and finally products that promise to use that fad to streamline the development process. This is all well and good, and over the years has yielded some genuine progress. The object oriented 'fad', and the design patterns 'fad' are two obvious examples of progress. The latest fads are extreme programming and aspect oriented programming. It's still a little early to pass judgement on these.

In spite of this progress, there are some areas of our craft that are more resistant to attempts at improvement. Defining the actual nuts-and-bolts of system behavior is one. Yes, we have made progress in this area -- witness the wide adoption of Use Cases to capture a description of the desired behavior of a system. But there is still no real short cut to the writing of the use case itself. A good deal of trial and error, and iteration must go into the description of system behavior in order to get it right, and while there is tool support to help, there's no getting around the give and take that tunes the definition of system behavior. This is especially true of any kind of system that interacts directly with a user. It's also especially true when describing the behavior of an interface between two separate systems.

One reason that this area of development defies attempts at improvement is because there is an information bottleneck. The person who owns the system requirements must communicate those requirements to other project participants. This is often challenging because the knowledge of what the system must do; what behavior it must supply, has never before been clearly articulated. It must be discovered. For a system that's being built in order to replace an older 'manual' system, there are no shortcuts to the process -- actually understanding the problem domain takes a lot of time; the communication bandwidth between the domain expert and the system architect is necessarily limited to their conversations. Tools can assist in providing a common vocabulary, but there can be no shortcuts in transferring the domain knowledge. System architects cannot perform a Vulcan mind-meld to acquire this knowledge. They must get into the trenches beside the domain expert and live that life for a while in order to really understand the domain.

The shortcut term I use for this dilemma is the 'Knowledge Problem'. This same term is widely used in flavors of economics (c.f. Hayek) and its impact in economics has some parallels to the problem we see in software development.

Are Experts Experts?

I've got a theory that the actual value of development advice is inversely proportional to the amount of time its proponent has to act as its advocate. If the advocate has lots of time to beat the drum for their point of view, it means they aren't spending a lot of time actually using the tools or approach that they advocate. Conversely, actual practitioners know what works, but very few have the time or take the time to describe what works.

This very rough analogy comes to mind. Suppose you are a soldier whose task it is to 'take that hill' (or whatever). Your platoon includes a sergeant, and an embedded reporter. The embedded reporter is very articulate, and writes well crafted stories about your situation. The sergeant is not very articulate, but has been doing the soldier gig for a long time, and knows what he's about. Whose advice on soldiering is more useful to you, the soldier? Are you willing to bet your life on soldiering advice from a reporter?

Advice from people who are writers first, and practioners second are plentiful, but not nearly so valuable as advice from people who are practitioners first, and writers second.

Gotta run.

Longhorn and Detroit II

So I don't 'get' Longhorn. What does that have to do with Detroit?

Back in the 1970's and 1980's, Detroit's automakers were under the first assault by the Japanese. We lived in Michigan at the time, and things there were bleak. I remember driving through Flint, Michigan and seeing every other house for sale.

How did the U.S. automakers get blind-sided by Toyota, and Japan, Inc.? I think a lot can be explained by the insular nature of the Detroit auto scene. When we drove around in Michigan, we had one of the very, very few non-U.S. manufactured cars. Everything else on the road was domestic, made in Michigan. Meanwhile, in the rest of the country, Japanese cars were selling like hotcakes. The Detroit manufacturers didn't know anything else about cars than what they learned from eating their own dogfood, so to speak.

That turn of phrase is a nice segue to Longhorn and its relation to Detroit. For years and years now, we hear from Microsoft how they run their business by eating their own dogfood. I can sympathize with this sentiment. It's something that I do on a daily basis with QVCS. However.... The lesson from Detroit is that it's real important to get out of that rut once and a while and taste the competition's fare. As it relates to Longhorn, it seems to me that Microsoft has been living in the Microsoft echo chamber for way too long, and have talked themselves into thinking that Longhorn is a great idea. You get the feeling sometimes that they are more interested in positioning themselves to collect the Microsoft 'tax' than in positioning themselves to serve their customers. Their kind of success necessarily breeds unwarranted confidence. Didn't IBM once fall victim to this kind of thinking?

Don't get me wrong. Microsoft still produces some great products and tools. But I've been working with both Microsoft tools and Java tools, and I've gotta say that Microsoft really needs to get out of the Microsoft ghetto to see what else is out there, or they'll earn the same fate as Detroit.

Longhorn and Detroit I

What a beautiful day -- at least for mid-February. Temperatures here (the Baltimore area) today are in the upper-50's (Fahrenheit). I just got back from taking a walk around the neighborhood. The snow is almost all gone. Spring is just around the corner.

I did get around to posting the 3.7.15 release this past weekend. It's primarily a maintenance release. Take a look at the new large toolbar buttons. My local graphics consultant (my daughter) fixed them so they are nice and sharp, instead of the blurry mess that they were.

After reading about the direction Microsoft is taking with Whidbey C++, I ran across another series of articles on Microsoft's Longhorn in MSDN Magazine. I guess I'm not drinking the Microsoft Kool-Aid anymore. I don't understand the motivation for Longhorn. It seems to lack a specific focus. What's the 'big idea' to wrap around Longhorn? Why would I rewrite my applications to take advantage of the Longhorn platform? I don't know, and it appears that Microsoft doesn't know either, or at least they haven't hit their stride with the message yet.

Examining Whidbey C++

I was catching up on some reading, and discovered an interesting article on the changes that Microsoft is putting in to their version of C++ for the upcoming 'Whidbey' release of Visual Studio (a.k.a. Visual Studio 2005). The article by Richard Grimes, (which is not available for free online), is in the December issue of Dr. Dobb's Journal. I won't go in to the gory details here, but, suffice it to say, these language changes look like Microsoft is trying to force all development onto C#, or their other managed code languages.

One of the virtues of C++ has been its general platform portability. These changes make it look like Microsoft is attempting to do to C++ what they tried (and failed) to do with Java.

Simple tools

Some tools which do useful things are difficult to learn and use. A possible example is Rational Rose. I haven't used it in several years, so perhaps it has since improved. But if it has become even more feature rich than it was back then, then it is only useful to that small population within the developer community who do nothing but use it. For the bulk of the developer community, it is shelfware.

In my experience, most developers are a Jack-of-all-trades. As a project begins, the developer participates in framing and defining the requirements; as the project rolls on, they are even more closely involved in design, and then implementation. This is especially true in the newer 'Extreme Programming' shops. As the work flows between requirements, design, coding, test, and deployment, the toolset varies. A developer juggles among the tools of the trade, needing to be fluent in a variety of tools. Tools that are easy to use are preferred because the developer does not have the time to invest in learning to use a complex tool. Tools that are hard to learn or use will be adopted by a small class of experts, and ignored by the rest of the developer community. In addition, complex tools will only survive in development shops large enough to justify the division of labor that allows complex tool specialists. For most shops, only a tool that a developer uses every day can afford to have any level of complexity. IDEs can succeed as complex tools because the developer is often immersed within the IDE provided environment for most of the day.

Version control tools are generally not used to the same level of intensity that is associated with an IDE. As a result, for the vast majority of developers, a version control tool must be very simple to use -- the average developer simply does not have the time to invest in learning a complex tool.

For this reason, among others, QVCS aims very squarely at the 'easy to use' target, and is purposely simple minded both because it makes it easier to write and maintain (for me), and because an 'easy to use' tool will be one that is actually used. For the vast majority of development projects, the QVCS product family supplies the functionality that's required. For the projects that require a broader feature set, those projects can afford the 'class of experts' staff to navigate the complexities that these more capable tools impose on their users.

This 'simple to use' constraint also helps explain why I've been slow to add more advanced features into QVCS. There are many features that are still needed in the QVCS family -- better branching support (for example). The challenge with these more advanced features is to add the feature yet still retain the ease of use that is absolutely vital for QVCS to be a success.

Back from Florida

I'm back from our annual Christmas trip to Florida. I was curious this trip to see what remained of the damage from the multiple hurricanes that hit the area (West Palm Beach) this past hurricane season.

Happily, South Florida has recovered pretty well from the hurricanes' effects. There are still homes with blue tarps on their roofs, and still places where there is a lot of debris. But things are close to normal. One nice thing (for us at least) was that traffic was not as bad this year as it has been in years past. In any case, it's good to be back home.

Since back, I've begun dressing up the web site that is bundled with the QVCS-Enterprise Server so that it will have a look similar to the Quma web site. Look for that in the next Enterprise build (I haven't decided on a release date).

For grins, I created my first poll on the Quma forum web site. The idea is to get some feedback on what missing QVCS/QVCS-Pro features are most important to users. It has not been much of a success yet -- only a single vote. Perhaps the vote total is so low because the products are already feature rich enough for most users? More likely the vote total is so low because as many people read the forums as read this blog.

Tweaking Enterprise

I've been spending the past several evenings cleaning up Enterprise code. I know, I know, it should already be clean... but in the real world, you wind up sometimes with something that is not as clean as you would like.

The tool I've been using to help with this mini-project is called findbugs. It's open source, and pretty useful. I can't say that it has uncovered anything significant, but it has helped me track down dead code, and other kruft that the compiler does not catch. Though I haven't yet integrated it into the Enterprise ant built script, it does have ant support so that I can automate its scanning of the source so it can catch boo boos automatically.

I found the findbugs tool at the java-source.net site. Highly recommended.

New look website

I finished dressing up the Quma web site this weekend. You're viewing the results. I updated the style sheet with based on some samples I found at this Ruthsarian page. The family helped with picking the colors, and my daughter did the banner and the merging of my picture into the banner.

Yes, that is me at the top of the page. I figured if Jonathan Schwartz can put his picture at the top of his blog, then I can too.

The content hasn't changed a whole lot. I did clean up the 'buy' page to make it more obvious how to actually buy QVCS products. Whether it makes any difference will be hard to tell, but at the least, it does seem easier to navigate than the earlier incarnation of the page.

Web site updates

Now that Enterprise 1.0.0.16 is out, I've taken some time to step back from development and evaluate the look of the Quma web site.

I'm not a web designer but have surfed enough (who hasn't) to know what I like and what I don't like. The current site has the virtue of being fast to load. It has a very simple look, and is uncluttered. However, it doesn't do a good job of inviting the visitor into the site, and the content does not do a good job of describing the products in a simple way.

In spending time thinking about the problem, I've discovered that writing good copy is not a trivial exercise. Nor is organizing the information that needs to get presented trivial. I've been tempted to just use a tool like NetObjects Fusion to help re-build the site, but I'm afraid that that would leave me with a site that lacks any unique character. Web designers will probably laugh -- they knock these things out in their sleep; but I want the Quma site to work for me -- which means I have to take the time to learn about what will make the site better.

So as part of that effort, I've been visiting other sites, and have come across several other sites that have useful content. You can see them on the blog roll to the right.

Eric Sink's blog is perhaps the most interesting to me. He is a principal at SourceGear, which publishes SourceGear Vault, a product that also serves the version control market. He's been working on a book that is an introduction to version control. I've skimmed through some portions of his work to date, and have found it to be well written and useful. Interestingly, SourceGear is located in Champaign-Urbana, Illinois. I went to grad school there some years ago. It's surrounded by corn fields, and is flat as a pancake, except for that pesky hill on Wright street.

QVCS-Enterprise 1.0.0.16 published

A week late, but better late than too early, at least for software publishing.

The week's delay gave me a chance to fix some things that I should have caught earlier. As a result, this build is the best Enterprise release to date, and is much more stable than earlier releases.

In getting things buttoned up today, I ran across another bug that had been lurking since the beginning. When I create a release, I use the custom Ant task of the product to create the build. This is both a convenience, and a simple way to test the functionality of the custom Ant task. In earlier builds, the custom Ant task would usually work and I had enough other things going on that I never took the time to figure out what was the cause of the problem. This time around, I decided I'd had enough -- time to slay this inconsistent behavior.

After several false starts, I finally figured out the source of the problem: it was a race condition that would only occur if the moon aligned a certain way -- i.e. it fit the observed behavior exactly, since prior to the fix, the Ant task usually worked correctly. Since the fix, the custom Ant task behaves very predictably, and I'm a much less frustrated user.

Among the other clean up things that made it into this release, the most significant bug fix has got to be the clean up of some subtle memory leaks. The largest source of leaks was within some code that made use of the Java ObjectOutputStream and ObjectInputStream. As it turns out, both of these classes hold on to references of the objects that are serialized through the streams so that if you are serializing an object tree, the serialization plumbing doesn't have to serialize the same object more than once. This makes these streams efficient for sending an object from one place to another, but it makes for a subtle memory leak if you leave the streams open for a long time and use the streams to serialize bunches of unrelated objects.... which is exactly what QVCS-Enterprise does when sending data back and forth between the server and the client. Of course, all this is documented after a fashion -- you just need to make sure to call the reset() method on the ObjectOutputStream in order to get the stream to discard any references that it is holding on to. The code does that now; it did not do it in earlier releases.

To verify that the memory leaks have been fixed, I tested the application with a project that contained over 11,000 files. Both server and client survived, and while client performance for a project of that size is slower than I'd like, it did work, and did not suffer from an Out of Memory exception. The same can be said of the server. Prior to these fixes, neither server nor client could handle projects of that size.

QVCS-Enterprise build 1.0.0.16 will be out by November 7

Well, I had thought that 1.0.0.16 would be released by now. I was wrong.

It turns out that I had to be out of town on a business trip over the weekend, and as a result didn't have the time to wrap things up for the build.

This, in hindsight was a good thing, since it gave me some time to profile both the server and the client application. That effort produced a happy result: I found several fairly significant memory leaks in both the server and client. Those memory leaks are now fixed, making the server much less likely to run out of memory than in earlier builds.

I also had a chance to put in a new splash screen, and add some useful information to the 'About' box. You'll get to see the results by Sunday, November 7.

Preparing for the 1.0.0.16 build

I finished coding of the final 'feature' for the 1.0.0.16 build this evening. It was much easier than I had feared.

The 'final' feature is a 'nice-to-have' for enabling/disabling the server's generation of reference copies at check-in time. I added a new set of check-boxes to the new project properties dialog that is in the admin tool. This new project properties dialog allows you to enable the creation of reference copies on the server. You can also disable the creation of reference copies on the server.

The 'nice-to-have' part of this feature is a couple of added check boxes that allow you to request that the server create or delete any reference copies at the instant that you click ok on the project properties dialog. This makes it so you can change you mind about whether you need reference copies well after the project has been around for awhile.

The deletion of the reference copies is a straight forward task -- just recurse through the archive directory structure, and delete any 'reference' files in the corresponding reference file directory hierarchy.

The trickier behavior was to have the server create reference copies for the entire project hierarchy if the user is enabling the creation of reference copies on the server.

This turned out to be simpler than I had thought it would be -- much of the hard work had already been coded in order to support the revision compare feature. Suffice it to say that it took less than 30 lines of code, and less than 2 hours of work. Cool.

Don't you just love it when things work out that way?

So, I'm on track to finish things up for the October 31 target date.

Forum Support now available

I just set up forum support. We'll see how it goes. QVCS Forums will take you to the home page of the forums. You need to register in order to be able to post to the forums. Hopefully, we can build up some body of knowledge there that users can have easy and searchable access to.