Pegasus Mail and Mercury Developer News
My, my! Time flies when you're having fun, and sometimes even when you're not, it seems.
The last time I updated this page, I was struggling with a nasty deadlock issue in Mercury; since that time, I have managed to fix that issue and bring out a public beta of Mercury v4.80, but the struggles didn't end there. The public beta exposed a number of other unrelated issues that it has taken time to fix, but we're finally there now, and Mercury/32 v4.80 is an official release, with a far greater new feature set than I ever intended it to have. I also believe it will be one of the best and most stable releases I have ever done: I am quite proud of it, and of the effort my test team has put in to it.
You might ask, why has this taken so long? Why should it be such a struggle simply to bring out a new version of a well-established, reliable program? The answer is mainly 'history'. Mercury was originally written in 1993 as a special kind of program called an 'NLM', for a now largely forgotten network operating system called 'Novell NetWare'. I produced the first Windows version of Mercury in 1995, using quite a bit of code from the original NLM program. Since 1995, Mercury has grown and changed continually, as living software does, and has had a profusion of capabilities and features added to it that are far in excess of anything ever contemplated in the original code.
The problem is that this accretion of features has been done on an underlying code platform that is now more than twenty years old, and the result has been an almost chaotic blend of code styles and practices, with workarounds for various versions of Windows thrown in for good measure. This means that it gets more and more difficult to maintain the program with each new version of Windows and each new feature that is added. About five years ago, the difficulty of this process reached an apex, where the time taken to add any new feature, even quite a small one, had to be offset by a disproportionately huge investment in time and effort in testing and validation. Since that time, I have ploughed enormous ongoing effort in rewriting and modernizing the code to remove complications, improve robustness and reliability, and to make it much more maintainable, but this is a huge job - more than 100,000 lines of code already, and still counting.
Then there's the problem of backwards compatibility: this is the idea that a data file you created back in 1993 should continue to be usable by versions of the program released in 2015. I have always tried to make backwards compatibility a hallmark of the work I do - for example, a folder created in the original DOS version of Pegasus Mail in 1990 can still be read by both Pegasus Mail for Windows and the Mercury IMAP server in 2015. But these levels of backwards compatibility come at a price, and the older the program gets, the greater that price becomes. There is a huge amount of code and effort in both programs devoted to supporting data files and formats that many people probably no longer use.
And of course, there's the size of these programs: they are now very large - each on its own is a full-sized commercial-quality software package, yet there's only me writing, maintaining and documenting them. To give you a point of reference, I have a friend who runs a successful company making software not much larger than mine, and he employs more than fifty programmers, graphic artists, documentation specialists, web developers and support staff. Of necessity, this imbalance of size versus capacity means that I can simply no longer work as fast or produce as many updates as I could when the programs were smaller and more manageable; it also means that I have to choose carefully the things on which I focus my efforts - and I have to be pragmatic about that: I will always choose to focus on things like reliability and real-world features over pretty interface skins because I believe those are the things that most benefit my users, even though neglecting the eye-candy aspect of the programs comes at a cost, since for many people that's all they really see when they're evaluating them. To me, it's one of the sadder facts of the modern world that many people are much more interested in how something looks than in how well it will serve their needs, but I guess that's just the way it is, and grizzling about it, while possibly therapeutic, is largely pointless. <grin>
There is some good news though... Mercury v4.80 is much closer to version 5 than it is to version 4.7 - a lot of stuff is in there but not currently exposed, and as a result, I can assure you that you won't be seeing an untoward delay in getting the first v5 builds out once the dust has settled on this release. It's a slow process, and it has been very arduous, but the results are near, and I believe they will be good.
All the very best to you all.
[ Page modified 1 September 2015 | Content © David Harris