Shareware Beach

It’s been two months since I commented on Borland’s planned spin-off. Time for an update.

The release of BDS 2006 Update 2 shows that Delphi et al. are still in active development. If Borland merely wanted to get rid of the products at the best possible price, there would be no point in releasing a free update. I installed it this morning. The most obvious improvement is that switching between files in the code editor is once again virtually instant.

Allen Bauer has been blogging about the spin-off quite a bit. Allen is one of the leaders in the BDS/Delphi product team(s).

David I hosted a chat with several well-known long-time Delphi supporters and component vendors. I only recently got around to listening to the replay. The most interesting bit of information in the chat was given by David I himself around 70 minutes into the chat, where he talks about the status of the spin-off.

Obviously, Borland being a public company, David I and co. are legally limited in what they can say. But he did say that all the interested parties are investment banker and venture capital types. That’s good news.

There’s been quite some speculation in the Delphi newsgroups about potential buyers. Many expressed hope that this or that large software company would pick up Delphi and put their weight behind it. I think being bought by a software company is the worst thing that could happen to Delphi.

Delphi’s problem right now is that it’s owned by a company that’s not focused on development tools. Delphi competes for resources with the ALM products, and ALM is what’s getting the attention at Borland. If another software company bought Delphi, Delphi would simply end up in the same situation.

So what do these capitalist banker’s know about software development? Well, not much. And that’s the key. They’ll let the people who do know about the technical side of the business make the product development decisions, as long as the business is profitable. Since Borland claims their development tools are profitable, and 3rd party developers claim (in the chat) that the 3rd party market is still healthy, this should be an attainable goal.

It’s no surprise that Borland’s recent announcemet to spin off its development tools’ business sparked a new wave of “Delphi is dead” discussions in various newsgroups and online forums. Personally I think that Delphi’s future hasn’t looked brighter for quite some time.

Certainly, until we know who the buyer(s) will be, there is some uncertainty as to the direction they will take with their aquisition. However, it is certain that the people currently developing Borland’s development tools are very focused on driving their products forward. Though Borland has announced the spin-off as a sale, it looks more like a divorce to me.

For quite a number of years now, Borland has spent a lot of time and money on its “Application Lifecycle Management” business. Basically this is a bunch of software that makes it easier to manage large software development projects. This business is quite different from the developer tools business. ALM solutions are sold by salespeople to enterprise decision makers, while developer tools are usually sold through retail channels and web shops (just like shareware). Attempting to serve two quite different markets seems to have led to a split in the company. Another key point is that Borland’s developer tools are mostly home-grown in Scotts Valley, while most of the ALM products have been acquired by buying up other companies. That results in different corporate cultures in the two business units.

There’s also far less synergy between the two parts of Borland’s business then one might think. Surely, tight integration between development and ALM tools is a good thing. But the issue is that customers want choice, and too much integration could be perceived as vendor lock-in. A company using Rational might decide not to use Delphi because Delphi will only work (well) with Borland’s ALM products. Another company using Eclipse might think that Borland’s ALM products only work (well) with JBuilder. Such arguments would be difficult to disprove by salespeople, because any product will always integrate better with other products form the same company than with competing products. By splitting up the businesses, Borland is free to integrate its ALM products as well as it can with whichever development tools are popular, while the development tool business can connect its tools to any ALM solution.

My opinion is that the people creating Delphi, JBuilder, etc. want to leave Borland just as much as Borland’s management wants to sell off the development tools to focus on the sexier ALM business. Though we will never know the full story, I think it’s great that Borland is being open about its plans to sell. Though it may fuel some panicky discussions, it’s better than Borland having to deny rumors and then have to admit that the rumors were true after all when the deal is announced, as often happens.

When there’s talk about Delphi’s future, there are always people saying they’re switching to Microsoft development tools. I fail to see the wisdom in that. Sure, Microsoft’s development tools will always be ahead of all other development tools when it comes to supporting the latest Microsoft technologies. But there’s a flip side to that medal.

In the late ’90s, many developers chose Visual C++ and Visual Basic over Delphi because Microsoft is financially far stronger than Borland (which is true). Ironically, Delphi is still going strong, while Microsoft has pretty much abandoned Visual C++ and Visual Basic. VB is no longer being developed for Win32, and VB.NET is a different programming language. While Visual Studio 2005 supports C++, MFC applications can’t be easily ported to pure managed code.

Delphi, on the other hand, is still in active development for Win32 and Win32 VCL applications can be easily ported to .NET using the .NET version of the VCL. I’ve already ported most of JGsoft’s in-house VCL components to VCL.NET. This turned out to be very straightforward, even though some of the components are very complex (like EditPad’s text editor control). Essentially, any code using pointers needs to be rewritten. The only situation where you’re likely to deal with pointers in Delphi is when dealing with Win32 API calls. This gives me confidence to use Delphi to code for Win32 today, knowing I’ll have a straightforward upgrade path to .NET should I ever want it. Sure, Delphi will support new technologies like Windows Vista later than Visual Studio. Frankly, that’s fine with me. By the time Delphi does support Vista, most of my customers will still be using XP, and that will still be the primary OS I

All this is no surprise to me. Microsoft is a platform vendor. They make money selling Windows. Visual Studio is a complimentary product aimed at helping programmers crank out more stuff that requires Windows. If Microsoft wants to sell a new platform, like .NET to compete with Java, it’s in Microsoft’s best interest for programmers to start cranking out stuff that runs on the new platform, but not on the old one.

Borland on the other hand, or whatever the new home of Delphi will be called, is a developer tool company. They make money selling tools to make it easy for programmers to crank out stuff that runs on whichever platforms people are using. It’s in Borland’s best interest to make Delphi compatible with all the popular platforms out there, and to provide their customer base with an easy upgrade path when new platforms emerge.

Tools from a development tool company will always have greater compatibility with whatever’s out there than tools from a platform company, while tools from a platform company will have better support for that company’s platform than 3rd party tools. Which one is best for you depends on your goals.

I’ve been using Delphi 2006 for a little over a month now, and I must say I’m quite pleased with it. EditPad Pro 6 betas 4 and 5 are the first releases of JGsoft products compiled with Delphi 2006.

One major gotcha with Delphi 2006 that doesn’t seem to have received much publicity is that Borland no longer officially supports Windows 95 and NT4 as deployment platforms. Delphi 2005 already required Windows 2000 or XP for the development system, but still supported Windows 95 and NT4 as deployment platforms. This doesn’t mean that your Delphi 2006 application won’t run on Windows 95 or NT4, but there may be issues. If supporting Windows 95 or NT4 is vital, I recommend sticking with Delphi 7 or earlier.

The main benefit of Delphi 2006 is the new IDE. At least, new for those of you using Delphi 7 or earlier. Since Delphi 7 is what I used previously (and still use–I won’t migrate everything just yet), that’s what I’m comparing Delphi 2006 against. Some of the features I mention as new may actually have been introduced in Delphi 2005 or Delphi 8.

The new IDE does feel sluggish. I don’t know if that’s because it’s a .NET application, or because of all the new features, or both. However, it’s perfectly useful on my 2.8 GHz Pentium D 820, which is not exactly the fastest CPU you can buy. The IDE does not take advantage of dual core CPUs. CPU usage never goes above 50%.

The IDE enhancements that I’m enjoying the most are releated to the debugger. When you hover the mouse over an identifier, you get a tooltip showing the value it holds. In Delphi 7, the tooltip is pretty useless when the identifier is an object, since it just indicates the value of the pointer. In Delphi 2006, the tooltip shows a list of field values. If you click the + button you can expand the tooltip like a tree view to see inherited class values and the values of fields that are themselves objects. The same tree-expansion system also works in the local variables list and the watches. Very nice.

The local variables list is now also capable of showing the variables local to any of the calls listed in the call stack. That makes it very easy to check the state of calling methods, without having to set breakpoints in each of them.

Class completion (Ctrl+Shift+C) has gotten a little smarter. In Delphi 7, it will insert new methods in alphabetic order only if the methods are already in perfect alphabetic order. Otherwise, the new method goes at the bottom. In Delphi 2006, class completion makes a best efforts at maintaining alphabetic order, even if the methods aren’t alphabetically ordered. Double-clicking on an event in the Object Inspector now does the same.

Error insight is also quite nice. Just like the spell checker in many word processors marks misspelled words as you type, error insight marks syntax errors as you type. It does makes mistakes sometimes, marking correct code or missing certain errors, but I still like to keep it turned on. Its particularly useful for catching typos in identifiers or mismatched brackets or begin/end keywords. Its much more convenient to catch those right away rather than at the next recompile, when your brain has moved on to a different section of the code.

The many refactoring commands are also very nice. The one I’ve used most so far is to rename an identifier. It’s quicker than a search-and-replace because it works across units, and safer because it doesn’t mess up other identifiers with the same name (e.g. two classes with a property of the same name). The biggest disadvantage of the refactoring commands is that I keep forgetting to use them. I’ve been editing code without them for so many years making it hard to break my habits. I’m planning to learn to use the refactoring commands more often one by one, and gradually make myself comfortable with what then can and cannot do.

The good old tabbed component palette is gone. The new pallette shows expandable categories containing all the components with a glyph and their names. I actually didn’t like the new palette at first, because it took up a lot of space showing only the components of one or two categories. Accessing another category required scrolling. Though the tabbed pallete could only show one category’s components, it did show the tabs of all categories, making accessing any component a two-click process at most.

Fortunately, the new component palette is quite configurable. Just right-click on it and select properties. I set the button size to medium, which is the same 24×24 pixel size used by the old palette. I also turned off the option to show component captions. Though many of the glyphs have changed, I didn’t find it hard to get used to them. Now, I can access the components from the categories that I use most in an instant. I can keep the components of several categories visible at a time, without obscuring too many of the other collapsed categories.

Another big change is the embedded VCL designer. By default, forms no longer float like in Delphi 7, but sit docked in the code editor window. You switch between a form and its code by clicking on a tab. This works nicely on a single display computer, since it can’t practically display the designer and code editor side by side anyway. But when using a dual monitor system, using one screen for code and another for design is very practical. To do this with Delphi 2006, you first have to disable the embedded designer. Select Tools|Options in the menu, click on VCL designer in the tree at the left, and deselect the checkbox at the right.

The VCL adds a bunch of new components to the “Additional” category. TTrayIcon puts an icon in the system tray, and can show tooltips and balloons. TLabeledEdit combines a TEdit with a TLabel. TCategoryButtons is the component the Delphi 2006 IDE uses for its component palette. If your application needs some sort of object or tool palette that’s too big for a toolbar, this seems like a very nice component. If you use it, I do recommend you offer your users the option of showing or hiding captions, etc. like the IDE does. The TButtonGroup component shows a group of buttons just like TCategoryButtons does, except that it cannot categorize the buttons.

The TFlowPanel and TGridPanel components seem to have been inspired by the layout managers that Java has had for a long time. They make it possible to arrange components flowing from left to right and top to bottom, or in a grid. When the form is resized (and the layout panel along with it), the components are automatically reflowed or the grid is resized. Basically, these components relieve you of the task of specifying pixel coordinates and sizes for the controls on your form.

The Delphi 2006 IDE has been very stable for me. It’s not perfect, but not worse than Delphi 7. I’ve had two crashes where the IDE simply vanished after class completion gave an assertion failure. Sometimes, the IDE slowly starts eating up all available memory. When that happens, the code editor starts needing a second or more to process each keystroke. Saving the project, closing the IDE, and restarting it makes the problem go away. I suspect it’s a memory leak in one of the features like error insight that contantly monitor what you type. It’s a bit annoying when it happens, but nothing to worry about.

You will need a beffy computer to run Delphi 2006. While Delphi 7 always stays under 100 MB of memory usage for me, Delphi 2006 usually eats up about 200 MB or 300 MB. However, Borland does seem to have had some success in improving Delphi 2006’s performance and memory usage when compared with Delphi 2005. It also helps that Delphi 2006 can be started with just one personality. Instead of launching the IDE with all installed personalities, you can make it load just the one you’ll be using.

Delphi 2005 was almost unusable on my previous development system with only 512 MB of RAM. Delphi 2006 does work just fine on my notebook which has a 1.86GHz Pentium M CPU with 512 MB of RAM. But it’s definitely more comfortable on my desktop with has a 2.8GHz Pentium D 820 with 2 GB of RAM. You don’t really need a fast CPU (the Pentium D 820 is probably the slowest dual core CPU), but you’ll definitely want at least 1 GB of RAM to work comfortably.

Speaking of personalities, another big change compared with Delphi 7 is that Delphi 2006 not only includes Delphi for Win32 and Delphi for .NET, but also C# for .NET and C++ for Win32. If you plan to use C++, you do need to install Update 1 to upgrade the C++ personality from preview to production status.

So, would I recommend an upgrade to Delphi 2006? There’s a number of factors to consider. First, you’ll need a much beefier PC than you ran Delphi 7 or earlier on. Second, while the new IDE features are very nice, you’ll have to consider if they’re worth the money, particularly if you’re planning to stick with Win32 development for the time being. Based on the fact that Borland is now using years as version numbers, I’m expecting to see a new Delphi release every year. Borland’s roadmap for Delphi certainly seems to indicate that. DeXter, now known as Delphi 2006, was released late 2005. Highlander, focusing on .NET 2.0, is scheduled for 2006, and Delphi Longhorn, focusing on Windows Vista, for 2007. That’s going to make keeping up with each new version expensive. So you might want to plan ahead and look at the features you really need.

That said, I do feel more productive with the Delphi 2006 IDE than with Delphi 7. Particularly the debugger features I mentioned earlier are very helpful.

My feathers are ruffled each time I hear people in the software industry claim that producing bug-free or even bug-rare is unrealistic or impossible. They’ll come up with technical arguments about the difficulty of writing quality software and how expensive it is to fix bugs. The usual conclusion is that customers should stop whining and get used using to buggy software, or go back to pencil and paper. Sure, very few pieces of software are bug-free when they’re first written, and debugging is a difficult job. But that’s irrelevant.

Bugs are a business decision. If a company ships software with bugs in it, that’s because somebody decided to stop testing and stop fixing bugs, and ship the software in whatever state it’s in. The time to make that decision is when more testing and bug fixing would cost more than the loss in sales and support costs caused by the known and unknown bugs remaining in the software. Both these figures will be estimates, since the cost of fixing or not fixing unknown bugs can’t be calculated.

This business decision still does not mean all software has to contain bugs. The higher the cost of unfixed bugs, the more money a company will spend on fixing them.

Last July I flew to Denver to attend the Shareware Industry Conference. I flew the leg from Taipei to Los Angeles on a Boeing 747 operated by China Airlines. This aircraft has two major software systems on board: the avionics software (flight computer), and the in-flight entertainment system. These two systems are completely independent of each other, developed by different companies, to different standards.

The avionics software is the software that flies the plane. No, the pilots don’t fly the plane, the flight computer does. How many bugs would you tolerate in the avionics software? How many do you think Boeing left unfixed? How many people have ever been killed by software bugs in modern airliners? Zero. A flawed flight computer would immediately ground all 747s worldwide. Boeing would not recover.

The in-flight entertainment system is a completely different story. It’s not essential to the plane. It only serves to make the passengers forget how uncomfortable those economy seats really are. If the entertainment system barfs all over itself, the cost is minimal. Passengers are already out of their money, and most will choose their next flight based on price and schedule rather than which movies are on those tiny screens, if any. I was actually quite pleased with Chine Airlines’ system, which offered economy passengers individual screens and a choice of a dozen or so on-demand movies (i.e. each passenger can start viewing any movie at any time, and even pause and rewind). That is, until the system started acting up. It locked up a few times causing everybody’s movie to pause for several minutes. Once, the crew had to reboot the whole thing. That silly Linux penguin mocked me for several minutes while the boot messages crept by. X11 showed off its X-shaped cursor right in the middle of the screen even longer. Judging from the crew’s attitude about it, the reboot seemed like something that’s part of their training.

The 747 story clearly shows that bug-free software is perfectly possible, and that bugs are merely a matter of priority. Software developers usually have a reasonably good idea of what would cost to get the bug count down to a certain level. But they often have only a vague idea of the costs of leaving bugs unfixed. These can be quite a bit higher than having your in-flight entertainment system ridiculed in an obscure blog.

An obvious cost, though often difficult to quantify, are lost sales. People who stumble upon annoying bugs when using the free trial version are far less likely to buy. People who hear from others how buggy the product is are far less likely to even download the trial. As the software market becomes more and more commoditized, this cost will only increase. The more alternatives customers have, and the easier it is to switch, the less they will put up with bugs in your product.

Another direct cost is tech support. If your software eats up a paying customer’s data, that customer is going to eat up quite a bit of your tech support department’s resources. Larger companies often cheat in this area, staffing their tech support department with low-wage workers that can’t do much more than send out canned scripts. But in a small company, let alone a one-person shop, every minute spent on tech support is often a minute taken away from development and marketing, not to mention fixing bugs. Fixing a bug fixes it for all customers. An email apologizing for it reaches only one person, while a forum or blog post still only reaches a small percentage of customers. It comes as no surprise that many smaller companies are renowned for their attention to the quality of their products.

A real killer is code reuse. Code reuse is often considered the holy grail of software development, because it allows you to add large chunks of functionality to an application almost for free. But any bugs in the reused code come along for the ride. Fixing bugs in reused code becomes even harder because each time code is reused, more code will become dependent on its behavior. And obviously, more customers will be exposed more often to those bugs.

Software quality matters and can be achieved with desktop software just like it can with mission critical software. Recently, Microsoft has been criticized for delaying and cutting features from Windows Vista. But Microsoft knows exactly what they’re doing. Windows ME was a commercial failure because it was perceived to be less stable than Windows 98 SE. As a result, many system builders preloaded Windows 98 SE until Windows XP Home became available. Microsoft can ill afford to release Vista unless it’s at least as stable as XP. It would not only hurt upgrade sales, but could have Linux, Apple and/or Google jumping for joy.