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.

5 thoughts on “Progress DBMS – three lessons for ISV's including collective deafness”

  1. Hi Greg, about that time I was using DataFlex to develop custom database applications. They had all the same issues attempting to move to Windows. In the DOS world, DataFlex was great, but they jut couldn't make the leap to Windows very well.

  2. Hi Paul,
    I dabbled with DataFlex on and off but ended up competing with it really well, using Progress. Progress offered a server-based data engine, both on Unix and DOS networks and had really strong reliability and integrity because of it.
    Clients quickly learned that we didn't have a need for menu items that let them fix up the damage from systems that were powered off unexpectedly, etc. We also were mighty glad of it.
    However, I always respected the rate at which DataFlex code could be written and the level of abstraction that the people developing with it worked at. FoxPro continued that tradition. I attended some local Fox conferences to present SQL Server sessions for those looking to migrate or work with it. I was always struck by two things at Fox conferences:
    1. How totally passionate and committed their community was.
    2. How aging their community was. There was little "young blood" coming into it.

  3. 🙂 Ahhh….I haven't thought of Progress in years. I used Progress in the early nineties. I doubt I ever got close to level of depth that you did, Greg, but I remember regularly being frustrated with it. Sad too, seemed to have great promise.

Leave a Reply

Your email address will not be published.