Progress DBMS - three lessons for ISV's including collective deafness

Alphatross posted an interesting reply to my blog entry about LINQ and Entity Framework terminology. He asked if I’d worked with the Progress DBMS. I have. Here are my thoughts on it. Obviously others will have a different view of history but I mention Progress over and over again when I’m teaching classes as three examples related to them really hit home for me.

I worked with Progress for many years, starting in about 1983 through to some time in the 90’s.

When they started, they wrote a product that just made sense. They didn’t care about being compatible with any older code and made an application and language that enabled you to write good code quickly. The thing I love most about the product was its stability. We migrated sites over to Progress and they just went quiet. When you are an ISV, quiet sites are a good thing. For character based RDBMS systems, I still haven’t seen anything I prefer for the types of applications we were building.

Then Windows appeared.

Lesson 1:

Companies that have had a good run and good track record tend to build up a collective deafness and eventually seem to have no mechanism to hear it when people say “we don’t like your products”. Version 6.2 of Progress was wonderful. Version 7 of Progress was horrid. I didn’t like it. I told them that. Their marketing folk kept insisting that the lack of new version adoption was due to “you guys not wanting to move to Windows”. We kept saying “we are moving to Windows, in fact we’ve already done so but not with your product”. They just didn’t *want* to hear the real message and were deafened to that message by their own previous successes.

Lesson 2:

Windows applications need to behave like Windows applications. This seems simple but it’s very important. Progress didn’t “get” it. They kept producing versions of their applications which were Windows-like but which didn’t really behave like Windows applications. As one simple example, if they displayed items in a list box, there would always be a scroll bar, even if there was nothing to scroll. This is very confusing to a user who sees a full list box and a scroll bar and thinks there will be more found by scrolling. I asked why they did this and they told me reasons that had to do with keeping compatibility with their character-based (ie: non-Windows) versions. One key reason for the success of Windows has been the shared knowledge you get from the platform. It minimises the amount you need to learn about new applications as all applications (should!) behave in a similar way. 

This is the problem when you have existing legacy customers. If you endlessly try to keep backwards compatibility, you’ll eventually be run over by a new competitor that writes a new application that just makes sense for the current time and couldn’t care less about being compatible with your old code.

Lesson 3:

Another thing that drove me crazy with Progress was that I could never keep purchasing the same base license versions. As an ISV, if I did all my building and testing on say version 6.2K, that’s the version I want to install at customer sites. I don’t want to have my application supplied with 6.2L today or 6.2L+ tomorrow then 6.2M a month later.

For customers using my application, no new feature added to the system is going to change *anything* in a positive way as the application won’t have been built to use it. The best I could hope for from a new version is that the application would still work the same way it used to. All other possible outcomes are worse than where I am now, not better, except for the hopefully rare situation where there’s an underlying serious problem that I haven’t stumbled across in testing.

Software Engineering process matters much more than new versions. And the first rule is that you don’t keep randomly changing the underlying platform.

2008-02-25