Fog Creek Software
Discussion Board

Software Strategy: Maintaining Legacy Code?

Hey all,

Let me ask for some advise on providing product support.

One product I sell is a moderate sized mac application that is popular with my customers who are professionals and hobbiests in a niche market. It's bought by individuals and some consultants, but not companies. it's basically shrink-wrap software.

Most of the customers are interested in a OS X version so I am porting it.

My question is should I start dropping support for older OS's and processors. For example, my program runs perfectly on all mac systems from System 7 through the latest 9.2.2. Also, I have both a PPC processor version and a 68k processor version. The latest revision of my compiler doesn't even support the 68k processor anymore. Should I drop it? Also, requiring System 8.1 and up or 8.6 and up (required by the newer Carbon API) would result in simpler code with fewer conditionals. It's a lot more work to make sure it compiles for every possible target.

Technically, I can manage to create a single code base that will do everything, but it'll be more of a mess. I do like that I will only have to fix problems in one spot and I do not at all like the idea of having totally different codebases, which if it comes down to that, I'd rather freeze an old version and stop maintaining it in its own dead branch, but make available to users of really old systems, which seems to be one way other developers do it.

I guess my main question is - is there any business advantage to maintaining support for the older systems? None of my customers that I know of have *only* the older systems. Some run on both old and new systems, and most have newer systems.

One factor I think important is that it seems that folks with really old computers don't actually buy software; all of my new customers the last 12 months have had the latest and greatest.

So is there any disadvantage to dropping support for old systems? Those of you who sell your products to many customers, what choices do you make?

X. J. Scott
Friday, February 28, 2003

I'd ask my customers.

Shoot out a survey to your customers, asking how far back they need compatibility.  If nobody wants System 7 support, you can confidentaly drop it from your considerations.

Brent P. Newhall
Friday, February 28, 2003

>> One factor I think important is that it seems that folks with really old computers don't actually buy software; all of my new customers the last 12 months have had the latest and greatest.

I think this should be one of your main consideration.

Are you finding things that need to be fixed in the older versions or are you just providing upgrades? If they're paying for support/upgrades, you'll need to determine if it's worth the extra work for whatever income is coming in.

If they aren't paying for support/upgrades, the decision is pretty easy - drop the 68K and really old operating systems. Both are old enough that your users shouldn't be expecting you to continue supporting their systems.

Friday, February 28, 2003

You can ask the customers, but be prepared to read through the replies with a full salt shaker.
What people claim they want (if it is free to ask) is often far removed from what they would be willing to pay for.
As you noted yourself, there is a strong correlation between shelling out for new hardware and coughing up for new software. Sure, you will keep that old machine running, but are you going to count on it or invest in it? Old machines become dedicated to something, they do not change jobs after that.
Unless you are getting a good revenue basis from support contracts for the old code, give a resonable maintenance period and then retire the stuff. One very important thing: always offer an easy and complete upgrade path from the old versions to the latest and greatest release.

Just me (Sir to you)
Monday, March 3, 2003

Don't ask your customers whether you should continue support for Mac OS 7. Instead, ask your customers what hardward / software platforms they are currently using.

From this, you get a profile of your customer base. From there, go back over your support incident database (you have one, don't you), and correlate ratio of support incidents with the ratio of people using the platform. You'll find one of three things:

1. Even though MacOS 7 users are x% of the population, the incident rate is much less than x%. This means that most users in this category aren't changing anything. They're still using old stuff because it works well enough for them. You can safely drop support for this old stuff.

2. Even though MacOS 7 users are x% of the population, the incident rate is much more than x%. This probably means that you aren't doing as good a job as you think in supporting these users. Consider whether you are better off investing *more* in legacy support, of whether you are better off dropping legacy support since you're not doing right by these customers anyway.

3. The incident rate for legacy users is about the same as their fraction of the population. This says that what you're doing is working. Drop support only if you determine that you're spending more money on the old stuff than is worth it (and now you have some idea of the worth).

Jim Lyon
Monday, March 3, 2003

Good point, Jim.  I'd change my previous suggestion to be in line with yours.

It's always best to align yourself with reality.

Brent P. Newhall
Monday, March 3, 2003

Comparing ratios is very powerful; thank you for another way to use them to get more information than you realized you already had :-)

Bryan Ewbank
Monday, March 3, 2003

Thanks everyone for the helpful advise.

I went ahead and sent off a survey to the customers stating I was considering freezing older system support at the last version,  asking what their current setup was and if there would be any issues for them if new versions support only System 8.1 and forward or 8.6 and forward and dropping System 7 and 68k support.

I have not had any support issues from anyone with either System 7 or 68k for some time. I suspect it is because everyone has more modern systems, or perhaps because the code in those systems is pretty stable. And of course it will stay stable if I freeze that version, so likely that's what I'll do. Also, it's a big hassle to reconfigure to test for the old systems, requiring digging an old machine out of the closet, reconstructing project files for an older version of Metroworks, and swapping hard drives back and forth, so any minor benefits are outweighed here I think. Also realized that, having only so many hours in the day, my time is better invested moving forward into the future rather than fighting the ghosts of the past.

I think much of my reluctance has been my packrat sense, which makes it very hard for me to be OK with stripping out code and throwing it away. Gosh, but what if I need it someday, like if I am stranded on a desert island with only a 128k Mac Plus? :)

<side topic>
As an aside, regarding the valid issue brought up of revenue, I don't currently charge for updates as I consider the value  greater for everyone to have all the bug fixes rather than complaining about buggy software. Right now, bug fixes come out in the next upgrade since any reasonable upgrade cost would currently be less than the cost for me of maintaining a separate bug fix branch of a version. Though I may modify this soon as I am planning to break this program out into a product family with Lite, Regular, and Pro versions. Setting this up will have the side effect of enabling me to upgrade a 'version 2' customer to version 3-but-with-new-features-disabled, called 'version 2.5.3' (for example). I've seen situations where folks get really mad if they send in a bug report and get a letter back saying 'this bug has been fixed in the new version, which you can upgrade to for $x'. I have this idea of the ideal situation being where free bug fixes can happen for people but if they want new features of a major upgrade, a fee can be assessed at that time. Doing this without incurring the expense and trouble of maintaining a bug fix branch of old versions seems a worthy goal. (Impossible to do indefinitely though due to these issues like stripping 68k code and the like, but you are right that it's doubtful any customers expect me to maintain old systems forever.)
</side topic>

Anyway, thanks again for the help and insights.

X. J. Scott
Monday, March 3, 2003

*  Recent Topics

*  Fog Creek Home