Progress DBMS - three lessons for ISVs (including collective deafness)
A while back, I got an interesting reply to a blog entry about LINQ and Entity Framework terminology. The reader 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.
Background
I worked with Progress for many years, starting in about 1983 through to some time in the late 1990’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.
But during this time, Windows appeared and everything changed.
Lesson 1: Collective Deafness
Companies that have had a good run and good track record tend to build up a collective deafness. Eventually, they are unable to comprehend when people say we don’t like your product.
Version 6.2 of Progress was wonderful. Version 7 of Progress was horrid. I didn’t like it. I told them that. But they couldn’t hear this message from developers using their platform.
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.
The users simply could not be correct.
Microsoft had a very similar issue with Windows 8. I attended so many sessions where people who should have known better were telling users that that problem wasn’t with the software, it was with the users.
It wasn’t the users that were the issue.
Lesson 2: Breaking mental models
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. But new users don’t have that previous baggage.
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. That’s how Progress became popular in the first place, and it’s a lesson that they forgot along the way.
Lesson 3: Shipping a platform, not an application
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 didn’t want to have my application supplied with 6.2L today or 6.2L+ tomorrow then 6.2M a month later. The change in the platform might well break something.
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.
Urgent security patches are one thing, but changes in behavior are an entirely different issue.
Software Engineering process matters much more than new versions. And the first rule is that you don’t keep randomly changing the underlying dependencies.
2026-02-07