Random though: software life time

[Peijen]

How long should software's life time be? Sun's Solaris has four year life, windows have a bit longer and less well defined life time. Office system has about 3 year life time. If you were to create a software company how long would you dictate your software's life time.

Obviously there is a point to software life time is you sell them commercially, namely lower support cost and increase revenue during every release. But what about none commercial software? what should its life time be?

Sun's model is new OS every two year, but each OS has four years of standard support (whatever that means). I think four years sounded about right. Anyone has an idea what other major software firm's release schedule is like?

[Jonathan]

Non-commercial software should never die as long as someone has a use for the code. Why would you want it otherwise?

Here's an interesting take on software lifetimes from Joel Spolsky which I will condense and summarize for your reading pleasure. It takes about ten years to work out all the ideas and bugs in a piece of software. Once you have this ten-year-old stable mature product, you need to find another revenue stream because trying to get your customers to upgrade from a product that satisfies all their needs is like squeezing blood from a stone.

[Peijen]

Non-commercial software should never die as long as someone has a use for the code. Why would you want it otherwise?

I don't agree with this at all. Given what I have seen in this place, non-commercial software needs a lifetime more so than commercial ones. We are still running software from 1980, that makes it 25 fucking years old. We are talking about 16 bit c/vb code that made me want to kill people everytime I have to look at it.

Why? Because they never setup a lifetime for the software, and nobody ever planned to upgrade the software because 'it still works' it still works my ass. When we upgrade to xp those software failed, the solution? Have a win 98 machine that's not connected to the network so they can still run the program to print whatever they print.

By lifetime, I don't been it should be throw away, but a plan to upgrade or replace it with rewrite of program with something more current. One piece of software that I maintain (I rewrote the whole thing without premission, and only I know how it works) would stay here until 25 years later when some other programmer got fed up with it, unless the managment agree to have a lifetime for the program, but I doubt they want to even think about that.

I have been thinking about this for a while, and one of my co-worker told me at one of the bank he worked for they have a 7-year life time, that's their turn around time for profit model (whatever that is) and it just make sense to let all software developed to support whatever product die or upgrade with it.

Also by the token that non-commercial software shouldn't die (I assume you mean have no life time) we would all be running version 1.0 of everything.

[VLSmooth]

I agree with the fact a software's lifetime exists for as long as it's in use.

However, code should be refactored / upgraded as needed (read funding is available). Doing so saves tons of time, money, and effort in the long run. Btw, that's a good thing.

For me, such upgrades are typically tacked along with new enhancements. Our code base is constantly evolving, with tools to track issues and changes. We also do our best to minimize dependencies, maintain modularity/scalability, etc. etc. etc.

/common_sense

[Peijen]

An example of lifetime in my mind is version 1.0 have lifetime of 4 years, version 2.0 have 4 year, etc. Development and support of the software would be waterfall or spiral model.

I think this is a major issue with linux deployment. People doesn't have good idea when the next version of the library they depend on would be released and everyone is working against their favor version of library because that's what they like to use.

If every project follows the same strict release schedule say quarterly revision, yearly minor release, and 2 year major release cycle, with discipline of not breaking interface with minor release, open source project maintenance would be less ugly. Not that close source/commercial projects are any better.

[Peijen]

I agree with the fact a software's lifetime exists for as long as it's in use.

However, code should be refactored / upgraded as needed (read funding is available). Doing so saves tons of time, money, and effort in the long run. Btw, that's a good thing.

For me, such upgrades are typically tacked along with new enhancements. Our code base is constantly evolving, with tools to track issues and changes. We also do our best to minimize dependencies, maintain modularity/scalability, etc. etc. etc.

/common_sense

but it's not common_sense. Taking what you said at face value, a dos program written in assembly 30 years ago should still be refractored and upgraded as assembly, because someone still uses it. Ingore the fact that we have decent gui libraries today and the fact we have easier to understand and maintain language such as java and sml.

[VLSmooth]

Then don't take it at face value

As for new languages, etc, we've done that on several fronts, since we develop for multiple interacting platforms (CORBA/RPC fun). A strict adherence to standards (POSIX, etc) and modular in-house libraries make things relatively painless though.

[Peijen]

Then don't take it at face value

but there would be no argument otherwise

As for new languages, etc, we've done that on several fronts, since we develop for multiple interacting platforms (CORBA/RPC fun). A strict adherence to standards (POSIX, etc) and modular in-house libraries make things relatively painless though.

So effectively programs have lifetime even when people are still using it, unless your company is allowing people to program against older libraries indefinitely after it's upgrade/replacement have been put in place.

[quantus]

I think what's sorta being missed here is that every piece of software, no matter what it is, is going to have a life of about 5 years, maybe 7 after it is released and all work has stopped. Past that, the effort to keep around old systems just to run it, is next to impossible. There are so many dependencies, like libraries, hardware resource allocation, etc, that the only way to make a piece of software run forever is to freeze everything about the systems it is running on. Now, if you set up a virtual machine/hardware emulator, and that NEVER stopped being upgraded, then you could always run your old stuff anytime by just starting up your constantly maintained emulator.

On a side note, this sounds amazingly like "What format and on what type of media should I save my data so that I can access it forever and ever?"

[Peijen]

Joe is right, but I did mention hardware requirment in one of my rant.

[Peijen]

On a side note, this sounds amazingly like "What format and on what type of media should I save my data so that I can access it forever and ever?"

Ascii fixed width flat file

[Peijen]

Here's an interesting take on software lifetimes from Joel Spolsky

Do you have a link for the lazy?

[quantus]

On a side note, this sounds amazingly like "What format and on what type of media should I save my data so that I can access it forever and ever?"

Ascii fixed width flat file

On what type of media? Huh? Huh?!!

[quantus]

Non-commercial software should never die as long as someone has a use for the code. Why would you want it otherwise?

I think what is unsaid here is that the non-commercial software should be open source, and the people who are using the software essentially become the maintainers.

If there is no source and it is only compiled, then it will likely die within the 5-7 years I estimated. There's essentially nothing you can do about it except make your own life much harder by trying to maintain a system that will run the code. You can always go through the pains of archiving all the linked libraries that are used, and setting up a wrapper script that will update your ld_library_path to those libraries. The libraries may break in the future though because of updates to the OS. Old OSes might not run on newer systems for silly reasons like the hard drive is just too big and it doesn't know how to address into it. Emulation and virtualization is the only way to break the problem down to a small enough chunk that can be supported through future growth.

Strangely enough, this sounds like something a business could be set up around. How to set up systems so that you can use them forever and ever and ever. The only question is, can this be done cheaper than the cost of rewriting the code that's being propped up? I guess Java tries to solve this, but the Java VM just seems like the wrong place to put the break between virtualization and the real world.

[bob]

In Windows-land, if I needed to do audio work, I would still turn to my copy of CoolEdit 96, so that's about 9 years old now. I would also use Midisoft Studio, which, depending on the version (I have two copies), is in the range of 7 to 10 years old. I truly haven't come across better MIDI software than that, from a functionality/usability standpoint.

Office software shouldn't have a lifetime. Most of it does, though, because of forced upgrades. Word docs have become "standard" in many situations, and newer versions continue to introduce backward incompatibilities, which pretty much forces people to upgrade.

Of course, I still play 15-20 year old NES games several times a week. Well designed video games tend to have a lifetime that goes until the machine stops working, assuming no emulators available.

[Jonathan]

Unsaid assumption indeed. Although I wasn't considering the case Peijen had in mind, which was software written for a business which is not intended to be sold. There's a similar plan for that, though: always distribute source with your binary.

At my office, I have access to all the source for the in-house programs that I use on my workstation. When there were incompatibilities between our Linux 2.2 OS and our Linux 2.4 OS, I was the one who fixed them. It just makes good business sense.

The stupidest software lifetime issue I've seen is IBM's ending support for commercial AFS. The open version wasn't up to snuff, so we had to spend lots of developer time regressing to a shittier solution because there was no acceptable alternative cross-site file system. That did and continues to suck. It was working code and a work methodology that we had to completely trash.

Joel's website is:
http://www.joelonsoftware.com/

I'll look up the article I was thinking of later.

[Peijen]

The stupidest software lifetime issue I've seen is IBM's ending support for commercial AFS. The open version wasn't up to snuff, so we had to spend lots of developer time regressing to a shittier solution because there was no acceptable alternative cross-site file system. That did and continues to suck. It was working code and a work methodology that we had to completely trash.

And that's also part of my arguement, if there are well defined lifetime your company would've more time to find a replacement rather than scramble to put together a hack.

I think I mentioned this, but I consider verion 1 and version 2 of any software to be different software and should have individual lifetime

[Jonathan]

We did have a pretty well defined lifetime. In fact, we threw a bunch of money at the problem and extended support for an entire year. There just wasn't an alternative available. My argument is that this sucked, and I blame software lifetimes. And IBM. Software services, my ass.

[Jonathan]

"Good Software Takes Ten Years. Get Used To it."

http://www.joelonsoftware.com/articles/ ... 00017.html