Empirical software engineering case on approaches to handling multiple versions, one file with ifs or several versions of program

I face the situation of having programs doing sets of requirements where this is substantial overlap. The obvious example, is a software firm supporting multiple customers that have similar but different needs. A trivial example is that Customer One wants a blue screen and Customer Two wants a green screen.

There are two options for the code base. Have two different copies of
the program or one copy of the program with an if (or similar) statement to say which is which. Thus, in the above trivial example, one can have

if (CustomerOne)
    backgroundColor = Color.blue
else
    backgroundColor = Color.green
end if

or one can make two different copies of the program and one copy has

backgroundColor = Color.blue

and the other version just has

backgroundColor = Color.green

Of course, one can also read the desired color from the configuration file.

So this question might be: What should be put in the configuration file? When should we just copy the relevant source code files and just edit them?

One copy of the program goes into the code base for Customer One and
the second copy goes into Customer Two. The problem with the second version approach is obvious to all readers. When one has a
change to the common functionality, one has to make it in two different
versions of the program.

But the problem with the first approach to versioning is obvious when
there are significant differences between the two customer’s needs, say
the code differs in about ten percent of the lines–one
ends up with a complicated series of ifs and elses on the flags that
define the needs.

Are there any empirical software engineering works that compare these two approaches?

Empirically, one can mine the version control systems for projects,
e. g. github.com to try to get bug rates for code or projects that
use either approach. (See Michael Wedel, Uwe Jensen and Peter Gohner, “Mining software code repositories and bug databases using survival analysis models” ESEM ’08 Proceedings of the Second
ACM-IEEE International Symposium on Empirical Software
Engineering and Measurement October 2008 pages 282-284.
doi.org/10.1145/1414004.1414052.

Empirically, one can do controlled experiments, where a project is set up both ways with half the test programmers doing the same software maintenance or enhancement tasks in one way and half doing the other.
One can say that the time and error rate to do the same change to two different versions is more or less than the time and error rate to plow through the if statements needed to have the same version of the code figure out which configuration it should do.

Of course, this issue can be considered a “religious issue” and I am sure most of the readers of this post have discussed it with colleagues. Thus, the opinions that we all have, the anecdotes and even the wisdom earned by decades as a software development professional are not appropriate for THIS forum.

The question is, are there any rigorous empirical work, especially controlled studies that shed some light on this question
that probably all software developers often face? I searched in
google.com and scholar.google.com to no avail.

The background on why I raise these issues:

I am a member of a two-person team and we are now at this fork in the road.
We have a stand alone program that we now want to function as a client.
Specifically, a program designed to be used as one participant will
now be used as a client in collaborative work research.
But I still want to continue doing research in single-user mode.
Do we have two copies of this program–one for the single-user case
and one as a client or do we fold them into one module and have it read
a configuration file so it knows whether to try to connect to a server.
(A good analogy would be for a game development company that is developing a game that a person can play stand alone or as multi-user. In fact this software is termed the “Supreme Court Game.”
It is an experiment in a “you be the judge” type situation. Often,
we want the participants to be “one of the justices” on the supreme court or to be the only judge in other research.)

Also, see medium.com/hackermoon/configuration-files-suck-6daa9812f601
for discussing the advantage of using this alternative to configuration
files: Writing code in the programming language of the software development project for each case, such as each customer, where there would be a configuration file.

Here is a code snippet on how one reads the color name in a
configuration file using the Color class in java and reflection:

import java.io.*;
import java.awt.*;
import java.lang.reflect.*;

public class A131 {
    static String s;
    public static void main (String arg[]) throws IOException {
        FileInputStream ConfigFile = new FileInputStream ("config.in");
        StreamTokenizer ConfigIn = new StreamTokenizer (ConfigFile);
        
        ConfigIn.nextToken();
        s = ConfigIn.sval;
        
        Class C;
        C=Color.class;
        
        Field F;
        F=null;
        try {
            F = C.getDeclaredField(s);
        }
        catch (NoSuchFieldException nsfe) {
            System.out.println (" bad field on |"+s+"|");System.exit(-1);
        }
        catch (SecurityException se) {
            System.out.println ("system security exception ");
            System.exit(-1);
        }
        System.out.println ( "field = " +F );
    }
}

This relies on the fact that the Color class contains multiple static
Fields that define common colors.
Of course, it would be much easier
for the programmer to have the individual creating the configuration file
enter the three numbers for RGB!

New contributor

In my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system.

In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.
In case there are different teams, maybe one which takes the responsibility for the core project and customer X, another one for variants/forks for customer Y and Z, having each team maintaining different code variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants – it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers.

For both cases, the key point is to separate code and modules which may be customer specific from the modules which should stay general and common for all customers. That is the real software engineering challenge. This is where things like separation-of-concerns, the strategy pattern, dependency injection, data-driven programming or domain-specific languages (and a few other techniques) shine. They can all help to isolate the customer-specific parts of a program, and the smaller that isolated part becomes, the easier it is to maintain code for different customers with a small team.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects – wherever one produces such a fork of a “living” project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group (“customer”). This happens regularly from the smallest projects up to the largest ones (for example, look at the dozens of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.

Let me add a few words about your specific case: a program which can be used in a multi-user mode connecting to a client-server DB can surely be used by a single person, too – I don’t see a striking reason why this should be split into two different programs. Moreover, there will be not many “if-else” checks necessary in the code base. Instead, it should be possible to implement such a program in terms of N users, where N=1 isn’t treated differently from N>1. One may want to use a more lightweight database backend for a single person, and to provide two different database layers, and maybe there are some optimizations possible in single-user mode. Still I don’t see how it could make sense for a two person team to duplicate the program and maintain a lot of duplicate code.

Are there any empirical software engineering works that compare these two approaches?

Yes, one option is to have a team which exist to maintain core functionality, and another to tailor it further to a specific customer.

Another option is to enforce standardisation on your customers and purge variation.

I suspect this question is asked implicitly from the perspective that the two actual solutions have already been ruled out, and instead the implied question is how an unreasonably small number of people handle the bespoke software development for a large number of customers at once.

Unfortunately once you rule out what works, you’re not left with anything else.

You may as well be asking how does one architect design a thousand bespoke houses a week. It’s just not a reasonable position to begin from – you either scale by organising more architects, or you standardise to the point that you can churn out cookie-cutter houses from one plan.

There’s no magic formula that allows one architect to sit at the centre of a web whereby every house is fully bespoke yet he performs all the work alone.

In terms of the specifics of whether you have a stack of if-elses in the code, or different codebases per customer and a bunch of if-elses in your deployment procedures to determine which compiled copy goes to which customer, it’s really just a difference of granularity, isn’t it?

The more widespread the tailoring to each customer, the more likely if-elses in the code will not do, and the entire codebases will have to be forked instead. On the other hand, the more often identical changes would be made to multiple codebases, the more likely you’d want to keep a single copy and avoid overhead and error in making changes. Both approaches can ultimately be employed in parallel, in the sense that there can be both shared and bespoke code that is ultimately compiled together into multiple bespoke executables, but the shared part exists only once in source code.

Usually it’s not possible to predict ahead of time the exact nature and location of all future changes to software – and it’s certainly not possible for strangers here to do so. I suspect also that many changes might involve a mixture of bespoke and common functionality being altered at once, so no single approach would be optimal for these changes.

But exactly where the threshold between the two sits, and where both run out of steam completely for a single person or team, is a subjective judgment based on how much complexity you find you can handle.

Using configuration files is one valid option, and you should seriously consider whether a variant can be expressed through configuration values – this shifts much of the customization work from developers to either the users or “configuration engineers”.

However, when the final applications diverge too much, you might want to separate the functionality into one back end library and several front ends for the different purposes. That way, the central library can be developed independently from the various front ends, and those can be adapted to newly available functionality or different user needs when necessary, without affecting the library development.

Create one file per version and keep all the files synchronised, so you can use a diff tool to compare them.

Let’s say you have 100 differences between 5 versions. Your version with “ifs” takes 6 lines for ifs, and 5 lines for each version, times 100. You get one huge file that is hard to maintain, because each version needs to edit the same file.

Once you have one file per version, it’s up to you whether it is a configuration file, maybe a JSON file, or a C header file. As long as it’s easy for you to build and ship five different versions with changes in code, or identical code and each version just uses a different configuration file.

Filed under: softwareengineering - @ 22:22

Thẻ: copy-paste-programming, customization, versioning

Thiết kế website giá rẻ

Danh mục

Empirical software engineering case on approaches to handling multiple versions, one file with ifs or several versions of program