The Old Joel on Software Forum: Part 4 (of 5) - "basline" system evolves into various versions

"basline" system evolves into various versions

if you've developed a baseline system and started customizing for various customers, pretty soon you have several different versions to maintain for several customers and you realize your company doesn't have a baseline product, but a whole series of seemingly different systems to maintain, which is quite confusing to track and train people on.

what's a "proper" way to manage software versions? do you go with one single version and tell ALL customers to use the same system, or expect to have different teams to develop and maintain different versions?

(perhaps this is less a software development issue and more a sales issue?)

Jason C. Jaan
Tuesday, May 4, 2004

This is what branches are good for. You have a core set of code, each custom build gets a branch. Done right, it's dirt simple to merge fixes from the core into a custom build (or back).

Snotnose
Tuesday, May 4, 2004

"do you go with one single version and tell ALL customers to use the same system, or expect to have different teams to develop and maintain different versions?"

I'm confused. These two options are not mutually exlusive.

At first glance, this sounds like an ideal case for using an OOP aproach. Then each "version" will have some collection of objects to give it it's unique capabilities.

That way, each version doesn't need to "know" about all the other versions and the master "implementer" ("factory pattern??") doesn't need to know the details of each object.

Mr. Analogy
Tuesday, May 4, 2004

My standard approach is to make all differences between customer installations configurable. Consequently, all customers receive the same code, but different configuration files.

The code is more complicated, and you have to maintain all the config files. Still, the gains in terms of reuse are worth it. Plus, you can readily tweak the application without altering any code.

Julian
Tuesday, May 4, 2004

I'm with the configurable option. Give customers a way to configure their product to suite their needs. Maintaining multiple versions becomes a nightmare. Chances are anyway, if one customer needs a feature then another one will at some point.

MikeG
Wednesday, May 5, 2004

Best bet is seperate configuration if you can manage it.
This also means you can always ship the current code and you only have one build process and never link with incorrect object files.
Another advantage is that old code doesn't stop compiling. It may get broken but thats what regression testing is for.
The downside is that you will get code bloat. If you can get away with a plugin architecture then that problem goes away.

Peter Ibbotson
Wednesday, May 5, 2004

sounds like configuration is the way to go, although this thought would have to be adopted early in the development process.

our system is workflow related, where each customer will have different permutation of the same steps, so this would mean design the system in such a way that sequencing the steps is a configurable feature, right? using OOD?

Jason C. Jaan
Wednesday, May 5, 2004

I used to work for a company that made a fairly complex product. They decided that all customers would get the same exes, and only the config would be different. (Config was in a proprietary registry-like storage structure).

However, managing complex config turned out to be harder than managing code. Which is logical when you think about it: programming languages are a great way to communicate with computers. They have evolved over several decades, with input from many thousands of people. A custom config format, devised in a few weeks by one or two people, is hardly likely to be a _better_ way to communicate with the machine.

Following that experience, would choose this approach if I had to design a similar system in the future: make a core "library" of objects. Everyone gets those. (E.g. they might be packaged as a set of "core" assemblies in a .NET-based product). Then for each customer additional classes are created. They either use, or are derived from, the "standard" ones.

Of course, all of the above applies if your config needs are complex. If you can configure the product with, say, one simple ini file, then you should probably do so.

aNonnyMouse
Friday, May 7, 2004