Software versioning post (version 1.0)

Forums: Humor
Email this Topic • Print this Page

Software Versions

If you're one of those people who are dragged around by the software companies to buy their upgrades and just getting confused why the hell you should upgrade the already working software, this one is probably good for you.

1.0: Also known as "one point uh-oh", or "barely out of beta". We had to release because the lab guys had reached a point of exhaustion and the marketing guys were in a cold sweat of terror. We're praying that you'll find it more functional than, say, a computer virus and that its operation has some resemblance to that specified in the marketing copy.

1.1: We fixed all the killer bugs ...

1.2: Uh, we introduced a few new bugs fixing the killer bugs and so we had to fix them, too.

2.0: We did the product we really wanted to do to begin with. Mind you, it's really not what the customer needs yet, but we're working on it.

2.1: Well, not surprisingly, we broke some things in making major changes so we had to fix them. But we did a really good job of testing this time, so we don't think we introduced any new bugs while we were fixing these bugs.

2.2: Uh, sorry, one slipped through. One lousy typo error and you won't believe how much trouble it caused!

2.3: Some jerk found a deep-seated bug that's been there since 1.0 and wouldn't stop nagging until we fixed it!!

3.0: Hey, we finally think we've got it right! Most of the customers are really happy with this.

3.1: Of course, we did break a few little things.

4.0: More features. It's doubled in size now, by the way, and you'll need to get more memory and a faster processor ...

4.1: Just one or two bugs this time... Honest!

5.0: We really need to go on to a new product, but we have an installed base out there to protect. We're cutting the staffing after this.

6.0: We had to fix a few things we broke in 5.0. Not very many, but it's been so long since we looked at this thing we might as well call it a major upgrade. Oh, yeah, we added a few flashy cosmetic features so we could justify the major upgrade number.

6.1: Since I'm leaving the company and I'm the last guy left in the lab who works on the product, I wanted to make sure that all the changes I've made are incorporated before I go. I added some cute demos, too, since I was getting pretty bored back here in my dark little corner (I kept complaining about the lighting but they wouldn't do anything). They're talking about obsolescence planning but they'll try to keep selling it for as long as there's a buck or two to be made. I'm leaving the bits in as good a shape as I can in case somebody has to tweak them, but it'll be sheer luck if no one loses them.

Topic Stats
Top Replies
Link to this Topic

Type: Discussion • Score: 0 • Views: 795 • Replies: 14

No top replies

Ain't it the truth.

I've never understood why we let software companies get away with this kind of sloppy merchandising. "It's mostly workable, let's sell it." Can you imagine what would happen if any other kind of manufacturer operated like this? There'd be a million lawsuits filed the same day.

0 Replies

Early versions of Windows had different error codes. Microsoft once told a convention-full of users that they would never see such-and-such an error again; it would now be called a "general protection fault."

Soon after the new version came out, the support line started getting calls about the old errors, even though the new version would never report that error.

It turns out that several software vendors had faked the error message in order to hide the fact that they had not incorporated a particular feature....

0 Replies

Eva wrote:

I've never understood why we let software companies get away with this kind of sloppy merchandising. "It's mostly workable, let's sell it." Can you imagine what would happen if any other kind of manufacturer operated like this? There'd be a million lawsuits filed the same day.

All others do operate like that. The difference is that programming logic doesn't tolerate mistakes that other manufacturing does.

0 Replies

You certainly know more about programming than I do, Craven.

But are you seriously trying to convince us that software manufacturers DON'T rush their products to market, regardless of major errors?

Come now.

Most manufacturers are afraid to let major errors hit the marketplace because of potential lawsuits. Can you imagine GM releasing a new model that drove fairly well MOST of the time? Or Del Monte marketing a new can of green beans that USUALLY didn't make people sick?

I know if I submit articles with major errors, I will be out of a job by the end of the year. If my graphic artist turns publication files over to the printer that contain flaws, she'll be out of a job. If the printer makes any errors in the printing job, they'll have to do it over again on their own dime.

There is little tolerance for error in many jobs today. Software design, from what I (and the writer of DrewDad's post above) can tell, is not held to the same standards. They do seem to just throw stuff out there. That's why DrewDad's post is so funny. There's an element of truth to it.

0 Replies

A Priest was seated next to Paddy on a flight to Dublin .
After the plane was airborne, drink orders were taken. Paddy asked for a Rum and Coke, which was brought and placed before him.

The flight attendant then asked the priest if he would like a drink. He replied in disgust "I'd rather be savagely raped by a dozen whores than let liquor touch my lips."

Paddy then handed his drink back to the attendant and said, "Me too," turned to the priest said, "I didn't know we had a choice!" Drunk

0 Replies

In defence of programmers:

How well would a car work if they completely redesigned the engine every three years?

0 Replies

Eva wrote:

But are you seriously trying to convince us that software manufacturers DON'T rush their products to market, regardless of major errors?

Yes! Portraying it as a matter of not caring about the bugs is a really common characterization of programmers, but that's almost never the case for established software companies.

In most cases it was a specific use/platform/idyosyncracy that brought out the bug. And in pre-release testing it's not possible to catch them all.

The most telling tale should be to note that not a single piece of large software has ever been released without bugs.

Bug free software today means getting millions of variables perfect and many times is the result of changes to someone else's code base.

Quote:

Most manufacturers are afraid to let major errors hit the marketplace because of potential lawsuits. Can you imagine GM releasing a new model that drove fairly well MOST of the time?

If a single extra space were to cause a car to not drive well then it would happen with every single auto they produce.

As is, GM recalled 2 million cars a few weeks ago.

Quote:

I know if I submit articles with major errors, I will be out of a job by the end of the year.

What if you just happen to have an extra space, or carriage return at the end of the file, and it is only visible when you use Word 2000 (international version, not us version) on Windows 98 and open it directly from email (opening it other ways would work fine)?

That is the kind of thing that causes "major errors" in programming.

The last person who asked me for help simply had one space at the end of his file that caused "major errors".

Quote:

If my graphic artist turns publication files over to the printer that contain flaws, she'll be out of a job.

If your printer uses an older version of software they might not be able to open it, and it won't be the graphic artist's fault.

This happens all the time with our department and it's a good illustration of software errors.

In the software world, the end user will simply blame the graphic artist because the file "didn't work".

Software is rarely stand-alone. It will almost always employ libraries of code written, maintained and updated by others.

In my experience, less than 1% of the time an end-user has blamed a company for a bug has been correct.

Quote:

There is little tolerance for error in many jobs today.

There is NO tolerace error for software. Given that perfection is impossible the nature of software simply highlights the rare errors that anyone will have because software deals in absolutes.

Quote:

Software design, from what I (and the writer of DrewDad's post above) can tell, is not held to the same standards. They do seem to just throw stuff out there. That's why DrewDad's post is so funny. There's an element of truth to it.

It seems that way to people who don't understand programming and logical absolutism (remember that computers don't make judgement calls, a human might ignore or not notice an extra space but a computer won't).

The above, to me, speaks more about the impossibility of getting millions of logical routines perfect than carelessness.

To some, the quips about introducing bugs when fixing others is indicative of the carelessness with which programmers operate.

In reality, it is indicative of the complexity of so many logical pieces to a large puzzle. When fixing things, you will often make a change that some other logical absolutism you didn't even know about will puke on.

You might want to read this:

Quote:

"It doesn't work."
Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less.

http://www.able2know.com/forums/viewtopic.php?t=8835

0 Replies

Goodness - I really learned something!

0 Replies

I know it's complicated, Craven, and I don't mean to suggest that software programmers are sloppy. Not at all. My husband does programming occasionally for large control systems, so I am aware of how meticulous programmers are.

Quote:

As is, GM recalled 2 million cars a few weeks ago.

True. But GM didn't recall them the same day they went on the market.
It seems strange how everytime a new upgrade is released, it is accompanied by patches and explanations of how to get around the new bugs contained therein. This is extremely frustrating. If they know about the problems when it's released, why didn't they just wait a few more weeks and fix the g--d---- software to begin with?

Quote:

In most cases it was a specific use/platform/idyosyncracy that brought out the bug. And in pre-release testing it's not possible to catch them all.

This sounds like an excuse. It seems to me that a software company should have intimate knowledge of how its product is being used. The patches I've had to install usually result from errors interfacing with other equipment and software. And I don't have unusual equipment and software. Nor do I use programs to try to accomplish tasks for which they were not designed (such as trying to do detailed page layout in Word or trying to do illustration in Photoshop.) This leads me to think that software companies seem more interested in releasing a product that will hit the market at the most advantageous time than in putting out a completed product.

Quote:

Quote:
If my graphic artist turns publication files over to the printer that contain flaws, she'll be out of a job.

If your printer uses an older version of software they might not be able to open it, and it won't be the graphic artist's fault.

This happens all the time with our department and it's a good illustration of software errors.

In the software world, the end user will simply blame the graphic artist because the file "didn't work".

It is the graphic artist's job to find out what software the printer will accept before preparing files. Otherwise, the files have to be sent to a separate service bureau that can forward a usable file to the printer at the artist's expense. Or the file has to be sent to a different printer. (The last major publication we did turned out to be a 10MB file with two full CDs of support files...graphics, photos & fonts. It downloaded to press without a single hitch. Now THAT's meticulous work. I sent the artist a dozen roses, btw.) Whatever happens, though, it's not our clients' problem to deal with it. With software problems, however, I have to figure out and fix the problem myself which costs me considerable time and money. Grrrrr.

I'm sure you're excellent at what you do, Craven. It shows on A2K. Please don't take my comments as personal criticism, it isn't meant that way at all. Just reflects my personal frustration at having to deal with software bugs when I don't consider that my job!!!

0 Replies

Eva wrote:

True. But GM didn't recall them the same day they went on the market.

And patching on the same day is nearly unheard of in major software releases as well.

Quote:

It seems strange how everytime a new upgrade is released, it is accompanied by patches and explanations of how to get around the new bugs contained therein.

I sincerely doubt that you can find a single instance of a major software release that was accompanied by a patch within the same week.

"Every time" is just simply disconnected from reality.

"Bug workarounds" are usually documented because changes in a platform might break something. This is not always a bad thing and in many cases it is the way it should be.

For example, if I fix a security hole by eliminating a certain process, any other software that uses it will not funciton correctly. In many software releases the bugs that are documented are not within the controll of the coder, and they are telling you that a change they made (possibly necessary) will break someone else's code unless the other person updates it.

Quote:

This is extremely frustrating. If they know about the problems when it's released, why didn't they just wait a few more weeks and fix the g--d---- software to begin with?

You keep saying this, but you can't name any major software release where this was actually the case.

Quote:

Quote:
In most cases it was a specific use/platform/idyosyncracy that brought out the bug. And in pre-release testing it's not possible to catch them all.

This sounds like an excuse. It seems to me that a software company should have intimate knowledge of how its product is being used.

<smacks forehead>

No, it's not an excuse. It's a logistical reality. You are demanding what is tantamount to demanding that an automobile funcitons on any terrain.

No matter how initmate one's knowledge of the use of the software, one can't controll it. Any most "bugs" in software are due to people deliberately using software to its detriment.

Security "bugs" are frequently the case of someone finding an inventive way to try to break software. We expect software to handle any contingiency perfectly and blame it in hindsight but the reality is that some things have to happen before someone ever realizes that it even exists.

Software developers rarely controll all the variables. When I speak of "platform" issues I am talking about people having a software enviroment that they did not envision. Given that there are literally trillions of software enviroment differences this is not just an "excuse".

Quote:

The patches I've had to install usually result from errors interfacing with other equipment and software.

So the developer should have the good sense to have all the other companys' developers work the way they want right?

Quote:

And I don't have unusual equipment and software.

What do you consider "usual"? There are literally millions of differences between your computing enviroment and mine, and I don't consider my enviroment "unusual".

Quote:

Nor do I use programs to try to accomplish tasks for which they were not designed (such as trying to do detailed page layout in Word or trying to do illustration in Photoshop.) This leads me to think that software companies seem more interested in releasing a product that will hit the market at the most advantageous time than in putting out a completed product.

I understand that this is your opinion, but you have yet to offer any evidence of a single incidence where this can be shown to be true, and you are unlikely to be able to.

BTW, the next version of Windows is late. And it was advantageous for the entire computing industry for it to have been released a year ago.

Quote:

It is the graphic artist's job to find out what software the printer will accept before preparing files. Otherwise, the files have to be sent to a separate service bureau that can forward a usable file to the printer at the artist's expense.

My initial comment was about the issues incompatibility introduces, not responsibility.

In software one will have hundreds of thousands of such problems, regardless of responsibility it is an inherent logistical problem that often can't be solved on one end.

Quote:

I'm sure you're excellent at what you do, Craven. It shows on A2K. Please don't take my comments as personal criticism, it isn't meant that way at all. Just reflects my personal frustration at having to deal with software bugs when I don't consider that my job!!!

I'm not a programmer. I am not taking this personally.

However, I maintain that your criticisms of software development have little to do with reality and everything to do with your lack of understanding of how software works.

Software has no tolerance of errors. Every day people make mistakes that in the software world would mean a fatal error.

Non-fatal errors usually mean a contingiency that the developer did not envision. Sometimes this is negligence, but the sheer number of possibilities for error in complex logic means that it can often be something that was logistically impossible to predict.

But the end-user will neither predict or even understand it, but won't hesitate to place the blame regardless of whether they even know what the problem itself is.

0 Replies

Craven de Kere wrote:

"Every time" is just simply disconnected from reality.

Point taken. That was an overstatement. But it has happened to me more than once. I haven't saved stacks of printouts from years past, so there is no way I could document these instances to your satisfaction. Really, I shouldn't have to. I would be shocked if no one else here has had similar experiences.

Quote:

"Bug workarounds" are usually documented because changes in a platform might break something. This is not always a bad thing and in many cases it is the way it should be.

For example, if I fix a security hole by eliminating a certain process, any other software that uses it will not funciton correctly. In many software releases the bugs that are documented are not within the controll of the coder, and they are telling you that a change they made (possibly necessary) will break someone else's code unless the other person updates it.

Thank you. That is a very clear explanation. Still frustrating, but clear.

Quote:

The patches I've had to install usually result from errors interfacing with other equipment and software.

Quote:

So the developer should have the good sense to have all the other companys' developers work the way they want right?

Quote:

And I don't have unusual equipment and software.

Quote:

What do you consider "usual"? There are literally millions of differences between your computing enviroment and mine, and I don't consider my enviroment "unusual".

No, I was thinking of instances where the new upgrade had problems interfacing with other software produced by the same company (Adobe PageMaker couldn't handle some files created by Adobe Photoshop...and they're supposed to be companion programs) or common fonts could no longer be printed correctly on most HP desktop printers. Routine stuff, not unusual at all.

Quote:

I maintain that your criticisms of software development have little to do with reality and everything to do with your lack of understanding of how software works.

I'll kindly disregard your remark about reality, since your reality and mine are obviously different. However, you are absolutely correct that my criticism stems from a lack of understanding about software development. Absolutely. And I feel no need whatsoever to apologize for that. Development is not my job. My job is to USE the software.

I'm just like everybody else. If my car doesn't run the way I think it should, I will blame the manufacturer. If my printing jobs don't match the press proofs, I will blame the printer. And if my clients aren't satisfied, they will blame me. That's the way the world works. So I don't want to hear any whining from software people who think I should excuse the errors in their products because they have such a tough job. I sure don't get any sympathy when my work creates problems for the end users!

0 Replies

Eva wrote:

I'm just like everybody else. If my car doesn't run the way I think it should, I will blame the manufacturer. If my printing jobs don't match the press proofs, I will blame the printer. And if my clients aren't satisfied, they will blame me. That's the way the world works. So I don't want to hear any whining from software people who think I should excuse the errors in their products because they have such a tough job. I sure don't get any sympathy when my work creates problems for the end users!

Fair enough, I demand perfection in software as well, I just know that it's not possible and that some of the frustration is a cost of doing business.

Incidentally, here's a good example to highlight the interoperability/platform issues I spoke of:

Ever notice how dedicated applications that only do limited functions have software that rarely causes frustration?

A TV has software, but its functions are limited in scope and it has the right amount of hardware resources for its tasks and does not need to interface with anything it would have a problem with.

Computers are frustrating partly because of our expectations of them, we expect them to work without such limitations, while those limitations would eliminate many of our headaches.

Anywho, if computing evolves into thin-clients en masse, I think you would be happier. But that's a whole new discussion....

0 Replies

Now, now. If software were perfect, I'd be out of a very nice job....

Good point on the limits. The power of personal computers is that they can be programmed to do just about anything, and often are.

Quote from Larry Niven (or was it Pournelle?), ca. 1980. People don't hate computers. People hate lazy programmers.

0 Replies

Craven de Kere wrote:

Ever notice how dedicated applications that only do limited functions have software that rarely causes frustration?

A TV has software, but its functions are limited in scope and it has the right amount of hardware resources for its tasks and does not need to interface with anything it would have a problem with.

Computers are frustrating partly because of our expectations of them, we expect them to work without such limitations, while those limitations would eliminate many of our headaches.

Anywho, if computing evolves into thin-clients en masse, I think you would be happier. But that's a whole new discussion....

How true. But I would venture a guess that it's not going to happen, given that software companies have found it more lucrative to develop giant programs they can sell to as many users as possible.

I admit, I handle frustrations in dealing with people much better than frustrations in dealing with machines. I'm quite happy to let people like you and my husband work on computer bugs while I wrestle with clients, etc. I'd hate spending the majority of my time at a computer.

AWFULLY glad there are people like you guys out there, though! The world would be a much duller place without you. A2K has been a lifeline. Thank you once again for giving us this place.

0 Replies

Software versioning post (version 1.0)

Related Topics

Quick Links

My Account

able2know