QVCS-Enterprise 1.2.10 Released

I just posted QVCS-Enterprise 1.2. The main thrust of this release is usability improvements. The changes include:

• Support for the $Project$ keyword. It expands to the name of the current project.
• The main window now has a lot better keyboard support, so you can do many common things without having to resort to the mouse.
• Improved the handling of the $Version$ and $Label$ keywords (they are synonomous). The expansion algorithm for these now matches the expansion algorithm in QVCS/QVCS-Pro.
• Added the ability to ignore case in filenames. This is a useful feature for Windows only shops.
• A number of usability improvements to the admin tool.

More details are available here.

This will be a free update for users who purchased their license within the past year. For licenses older than that, you'll have to purchase a license update.

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 3.9.23 Release

The latest QVCS/QVCS-Pro release is now at 3.9.23... If you blinked, you may have missed the 3.9.22 release.

I created the 3.9.23 build to change one line of code so that the product would work for a user running a Novell 6 file server. The change had no effect on Windows file servers. Hopefully, this will be the last build for a while -- though if you have a problem, please report it. As you can see from the release history, simple defects get fixed pretty fast.

From the development standpoint, the variety of behaviors supplied by the different file servers is a nuisance. You'd think there would be some specification that they must all adhere to. Even if there is a spec, they do not supply the same behavior. I've seen different behavior for SAMBA file servers than Windows servers, and different behavior for Novell servers than for Windows servers. And of course, Novell 4 behaves differently than Novell 6. (The latest QVCS release works on Novell 6, but does not work on Novell 4).

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.

QVCS/QVCS-Pro 3.9.21 Release Now Available

I just posted the 3.9.21 build. It is mostly a bug-fix release, as you'll note if you look at these notes.

Thanks to Dirk for helping narrow down one of the bugs. Almost all of the bug fixes in this build are to fix user reported bugs. As I've noted before, I can't fix a bug unless I know about it.

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.