2

I'm trying to pass a point to my team whereas there are two different kind of "programs" we can serve : applications and executables/librairies.

An application in this sense is dependent on other parts (think microservices), it has to match certain configurations or enforce certain security fix so it knows how to work at a present time. For example. Gmail would be an application, you can't choose which version to use when using it.

An executable or a library is context dependent, at a given time, it does a "thing" in a given way and it is working for that given purpose on that machine. For example, python 3.4, python 3.5, etc.

At my work we serve both to users. Historically, users could choose which version of an executable they'd want. More recently we developed more complex applications and i'm kind of trying to explain why this can't, IMO, not work for users to choose a version. My colleague wants to keep using the version tool we have but I think it can't be applied.

So how would you distinguish programs that can be used with a specific version and others that can't. Are there any terms to speak about it? Am i missing something?

How would you stress out the problems that can occur if users start using older versions knowing that this will increase the time spend giving support to users, telling them to upgrade, etc.

P.S.: In this application context, we have full responsibility for retro-compatibility.

Edit : For more context, i work in a scientific environment where everyone is on a terminal launching jobs. Some "executable" (shell command) are built has microservices. You'd use them like any shell command. We push binaries to a selected path where users can fetch the binaries via the version tool program. That selected path contains many versions of a given program.

  • 1
    The fact you cannot choose which Gmail version to work with is exclusively caused by the fact it is a Web application provided by Google by a continuous deployment process, and Google decided only to provide users with one version (sometimes they also provide an "old" and a "new" version to pick for users, allowing them - and Google - to test how the new version works in the wild). – Doc Brown Apr 5 at 16:07
  • ... however, noone will hinder you to have different deployment cycles even for Web application and give each new release a new version number. Or in other words: I have no idea what you are asking about, it is totally up to you which applications you deploy in a form the user can pick a version, or not. So what's your question? – Doc Brown Apr 5 at 16:10
  • Where's the line between offering a "pick a version" or not? How do you decide on this? What makes a program a good candidate for one or the other? – Pobe Apr 5 at 16:24
  • Ok, but the question title seems to be unrelated to this; the usual meaning of the term "application" has nothing to do with the possibility to pick different versions or not - that sounds very confusing to me. Better find a different title. – Doc Brown Apr 5 at 22:04
2

Historically, users could choose which version of an executable they'd want. More recently we developed more complex applications and I'm kind of trying to explain why this can't, IMO, not work for users to choose a version. My colleague wants to keep using the version tool we have but I think it can't be applied.

Users could choose which version to use. It's not clear why you would need a "version tool", why you would use "software configuration management" and "configuration management software", when (as you describe it) "everyone is on a terminal launching jobs".

The end user simply wants to use version X or Y (1 or 2) of a particular program because that's what works for them - either it's what they know how to use or it's what works with their data format or other programs.

If they are clicking a desktop icon or typing on the command line they'll have to get used to the fact that there'll be a number on the end of the name or you'll have to set up their computer so that they type (or click) just a name (no number) and what comes up is what they arranged for.

As support staff you'll have to choose between supporting multiple versions and hopefully answering few questions or training some of your employees on the newest version and suffering with the learning curve and complaints.

So how would you distinguish programs that can be used with a specific version and others that can't. Are there any terms to speak about it? Am I missing something?

Always supply the newest stable version for the user and develop training ahead of time for the next version you want to switch them to (after it is stable). With open source software that's not too difficult, with closed source proprietary software you probably won't have access to early releases and there will be a lag between learning and productivity (should you decide to upgrade).

The end user (and the owner of the business) just wants to do the work and get it done. Presumably you will be more efficient by doing less work (less fixing and less support) while the end user is more efficient by doing more work.

So you'll want to decide the balance between fixing, teaching, and upgrading - and prepare a plan that allocates the correct amount of resources to each part, with the goal of decreasing the amount of work, and especially duplication (redoing) of work.

How would you stress out the problems that can occur if users start using older versions knowing that this will increase the time spend giving support to users, telling them to upgrade, etc.

See above.

P.S.: In this application context, we have full responsibility for retro-compatibility.

Edit : For more context, i work in a scientific environment where everyone is on a terminal launching jobs.

From a comment:
Where's the line between offering a "pick a version" or not? How do you decide on this? What makes a program a good candidate for one or the other? – Pobe yesterday

Plan what works best for your department (less work and complaints) and what works best for the company (less complaining and more work done).

Keep it simple, but keep it working and the versions used recent. Decide if there's a good reason to upgrade to the newest version and develop a plan to advance forward together.

PS: I always use the bleeding edge version and leave the office on the latest working version until it's unproductive for them to be behind, then I sell the owner (whom often is also using a newer version than the rest of the office) on some training time to move everyone forward.

If there's some reason to support legacy systems (for the sake of some customers) then maybe you need to seperate part of your employees into two groups, one group just does the work that comes in and a specialist team that supports customers with special requirements (for premium rates).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.