CIOs Band Together Against Paying For Software Bugs

gmerideth writes: "This article over at cio.com interviews several CIO's who are sick and tired of spending billions every year on software upgrades simply because the creater tells them to upgrade as they wont support previous versions or they get stuck into lengthy, costly licenses. Quoted from the article "Other companies, such as Ameritrade Holding, are opting for open-source technologies such as the GNU and Linux operating systems, the Apache Web server and Sendmail e-mail.". It's glad to see the open source movement doing it's job."

Comments

Planned Obsolescence

[jason99si]

Sounds like the software companies are sounding more and more like the electronics and automotive industry.

In the automotive industry, people are encouraged to dispose of their perfectly good cars due to new features on new models and increasing prices of replacement parts... although their car is perfectly fine.

I remember hearing something about GM phasing out model years on cars... but haven't heard anything since, they must have come to their senses.

Or how about when the knob breaks on your stereo and it costs as much to replace the knob as the stereo.

Consumer backlash? People still buy new cars and new stereos...

Re:Planned Obsolescence

[gmhowell]

Take your analogy another step: over the past 10-15 years, there has been a big push by auto makers to encourage customers to lease cars. After 2-4 years, return your old car, begin a lease on a new one.

Similarly, Microsoft is switching largely to this new leasing model.

And in both instances, it is for the same reasons: features are no longer improving. During the 50's, 60's, there were model year changes in autos each year. Look at the shoebox Chevy's (55-57) While having the same underpinnings, each year had different trim, a new look, etc. Flash forward to the 'new' shoebox Chevy, the '87-'93 Ford Mustang. Almost identical. Not even the cosmetic changes of the older models.

Now look at Microsoft: big difference between Win 3.1 and Win '95. Not so big to '98, not so big to ME...

There is no technological need to upgrade in either industry. So force a revenue stream by only renting the product.

(BTW, I hope and prey that Bob Lutz will help get GM in gear. I've never owned a GM, and while there is nothing inherently wrong with their product, there is no compelling reason to buy it. DCX really screwed up when they let him go.)

Re:Planned Obsolescence

[plover]

Absolutely. It's Microsoft's revenue stream, and while they don't like to admit it, they don't deny it.

The problem they've come up against is that they've feature bloated their software to the max. It's common knowledge that people don't know how to use 95% of the features of their word processors. Ten years ago, that number used to be 50% ignorance. They sell "new" software with more "features" because their revenue stream model forces them to market "new and improved," not out of any consumer demand.

Thus the birth of .NET. A subscription model. Same product, but now with "fewer hassles." Make it attractive to developers by pushing the hell out of it in the magazines and with evangelical meetings. Make it attractive to consumers by offering them magical promises that it "keeps up automatically with the latest features." They don't even have to think up those features today. It's like buying cleverness on credit!

Oh, yeah. I almost forgot. Microsoft gets a monthly rent check from you, too.

John

Re:Planned Obsolescence

[the_2nd_coming]

Sounds like the software companies are sounding more and more like the electronics and automotive industry.

Except that in the Electronic and Automotive industries, you can always find a 3rd party verdor to support your equipment, in the MS world, you can't since the code is closed.

Re:Planned Obsolescence

[tshak]

Now look at Microsoft: big difference between Win 3.1 and Win '95. Not so big to '98, not so big to ME...


Please take no offense, but this is a highly uneducated observation. Win95 to 98 was not a dramatic rewrite of the OS, true, but the change was huge. It is so much easier to support 98 then 95, for a whole slew of reasons. ME is an even bigger step forward. Sure, on the front they all look very similar, but they are definatly reasonble upgrades. Then, take 2000 and XP into account, and you have yet another "leaps and bounds" improvement.

Weird.

[sulli]

Here we have CIOs saying they want to pay subscription rates for software:

Fortunately, there are a host of alternative solutions on the horizon, and a growing number of CIOs are determined to make them a reality. They include renewable licensing agreements, in which CIOs purchase the right to use software for two to three years at about 85 percent of the cost of what they'd pay under a perpetual license. CIOs then have the option to renew the license at the end of the term if they're happy with the quality of the product and the support. Subscription licensing agreements are similar to renewable licenses, except the term is shorter, lasting about a year, and CIOs rent the software, as opposed to owning it.

Aren't they just playing into the hands of vendors who want to increase ongoing revenue for product they used to just sell once? I don't get it.

Re:Weird.

[Anonymous Coward]

The CIO's in favor of the subscription model think that if the software doesn't work, they can refust to pay the rest of their subscription or just switch to another product when their subscription is up.

The problem with the subscription model is you have a drop dead date. If you do not switch to another software package by the time your subscription runs out, you cannot continue to legally use the software. Furthermore, if you don't upgrade when the software vendor tells you to, you cannot continue to legally continue to use your current systems.

Imagine what would have happened to that CIO if his company couldn't meet payroll because oracle had forced them to upgrade to Oracle 11i which didn't work yet.

Not only the upgrades

[Green Aardvark House]

The money that can be saved is not only in upgrades, but virus prevention as well.

The company I worked for wasted thousands of dollars when the Nimda virus struck. To a small business, this cost plus a day's worth of downtime can be a significant hit.

If we used the open-source alternative, we might have saved this money.

software sales model change?

[daoine]

...own the software and the right to use it "in perpetuity." The problem with this model is that in reality, CIOs are lucky if they can get three years out of a product before vendors release entirely new versions of their software. Vendors further pressure CIOs to buy those new releases by threatening to stop supporting previous releases-a tactic they often take both to cut their tech support costs and to get CIOs to pay again and again for what is essentially the same product.

Microsoft's changing of its licensing practices has clearly pointed to a flaw in the software sales model -- in small doses, companies will put up with it because it's easier to maintain status quo than to radically change. However, companies are now looking at a tripled technology budget -- and they're looking seriously at how things are working.

They've figured out that some of it sucks.

The problem with the current software sales model is that it is impossible to tell the companies that will support and stand behind their product from those that will rake you over the coals. When companies have the ability to change their licensing agreements overnight, the consumer has no ability to chose the good from the bad.

The good thing from this: people might REALLY take open source seriously.

The bad thing: I think a lot of well-run, fair and supportive software companies are going to suffer because of the greed of the others.

Corporate Acceptance

[LazyDawg]

While it is true Linux and other open source software will be successful as long as one person somewhere finds it useful, it is nice to finally see corporate acceptance of this software.

What does corporate acceptance mean? It means we have become cheaper to set up and maintain than the other options for the corporate world, those being Windows and MacOS.

Linux still has its original stability and low price tag, and there are now several versions of all the software that corporate customers formerly had to develop for.

Macintosh lost out to Windows in the corporate marketplace for the same reason so many companies are switching over to Linux now. Installing Windows on a pre-existing IBM DOS box is a lot cheaper, and there were more applications. We now have the same applications, possibly fewer in number, but lower in price, so companies are turning their head toward the other option.

Companies are predictable buggers. If you give them a cheaper option with the features they're looking for, they will jump on it. Every time. Linux developers only need to ask what those features are and include them in the core OS or surrounding software, and we'll enjoy even greater corporate acceptance.

Re:thank heavens

[SilentChris]

It's less the end user and more the IT manager. The user rarely, if ever, knows that a new upgrade will do the "trick".

Case in point: a user of ours was having difficulties saving extremely large PowerPoint presentations. We tried everything we could to get Office 2000 to corporate (including numerous MS Knowledge Base-suggested fixes). The end result: the only way we were going to fix it was to "upgrade" to Office XP.

Was there another solution? Sure. We could have kept the hacked registry keys and crossed our fingers. The user would have never known the difference. The problem here, though, is what is a "bug" and what's an honest-to-goodness limitation of the current version of the software.

Another point on that note: many of the limitations set aside by developers (in the number of pages a document can have in memory, the number of rows a spreadsheet can include) are forecasted not by them but the limitations of the current technology. Sure, if MS used a less pretty office assistant they can save a few megs for that spreadsheet. But the bottom line is, at the time, developers of older versions of software did not, or simply were not able to, think ahead.

Which leads once again to my question: what's a bug and what's a limitation? That will determine whether people will pay for an upgrade.

While I admire their resolve...

[mystery_bowler]

I don't think this is going to stop companies from releasing software that has bugs in it.

I do believe that market rejection could place tremendous pressure on software vendors to put more effort into bug-testing their product thoroughly before it is used by the client. But bug-testing is a time and resource consuming affair. No software company, no matter how big and fat with cash can throw enough money at a product to make sure that every possible scenario is covered. It is only a matter of time before a bug (perhaps even a significant, critical one) is found.

But still, I appluad the efforts of anyone who is willing to tell their software vendor(s) to try harder to get it right. I sincerely hope this strategy will convince the software vendors that purposefully release broken products to stop assuming we'll upgrade when you release the "professional-special-app-of-the-year-gold-box" edition of the software just because this version fixes that nasty, data-ruining bug in the last version.

I think it's worth noting, though, that only one thing can truly lead to the elimination (or near-elimination) of software bugs: developing for a limited number of platforms/OSes. The more OS/hardware possibilities you bring into the picture, the more bugs you'll have. Guaranteed.

Of course, similar arguments could (and should) be a applied to the PC games industry, but that's another debate. :)

Re:While I admire their resolve...

[dillon_rinker]

I don't think this is going to stop companies from releasing software that has bugs in it.

I don't think anyone (except PHBs) truly believe it will; I don't even think it can. Software is inherently buggy unless you pay orders of magnitude more than you can afford to (good, fast, cheap)

What CAN happen is that vendors be forced away from saying "This is a known issue. This is fixed in the next version of Product X." In other words, force vendors to provide free bug fixes. Perhaps EULAs should specify an end-of-life for the product; then purchasers KNOW exactly what they are getting.

The better licensing plan

[AKAImBatman]

I think that their are several places here where the licensing needs to change to please businesses. First and foremost, companies should not get rid of perpetual licenses if they server home users. These users are used to being able to buy something (car, radio, computer, microwave, etc) and own it for life. That being said, I think that IT managers would like to be able to lease software again like they could in the mainframe days. Instead of paying a lump sum and then paying a maintenance fee, they will be much happier if they can play money games with their budget so that the costs are stretched across the life of the product and in fact reflect themselves in the operational costs.

The other scheme I would like to see return is the purchase of business logic software WITH the source. Back in the days of mainframes, if you needed accounts payable, accounts receivable, order tracking, etc., you would buy a package of software that would come with all the source code so that you could change the logic to fit your business. This was actually a requirement then because the DB access code was compiled into the program resulting in binaries that were tied to the schema. However, the side effect it produced of giving the source with the product was extremely successful due to the fact that no two businesses are alike. Just because Kraft does their paperwork this way, doesn't mean that GM does theirs the same. Plus, Kraft has to worry about delivery schedules via networked partners such as Sysco whereas GM ships directly to dealerships.

As much as people may hate to hear this, the mainframe guys had it right and business today should start taking notice of that.

Re:But the problem still remains...

[dillon_rinker]

The more Oracle/Microsoft/etc squeeze to inflate their bottom line, the more people abandon ship and switch to OS.

Ahem...

"The more Oracle/Microsoft/etc tighten the grip, the more systems will slip through their fingers."

Wait a minute. Somebody's shifting blame.

[dinotrac]

I don't wish to excuse any vendor for delivering crapware. Bad vendors should go out of business.

That's the problem.

If CIOs would cover their damned butts they wouldn't get into these binds.

It's good to hold Oracle's feet to the fire. It's good to make them sweat and to make them deliver.

But...

Why aren't these CIOs demanding reasonable back-out strategies?

Twenty years ago, when I worked for EDS, clients routinely demanded that we use particular technologies so that they could kick us out if they didn't like us.

At another employer, the only patents I've ever had my name on (inventor, not owner. No money for me) came because we didn't want to be locked into AT&T as a long-distance provider. They had a special feature we wanted called Network ACD, but it was patented and no one else could offer it. We spent the time and money to invent our own system and stay free to negotiate with whomever we pleased.

I'm amazed by these people who are talking up subscription software. Nothing wrong with the concept, really -- if you've got a way out. Then it's like a lease-or-buy decision for anything else.
With a lock-in? Come on. Surely they've noticed that Microsoft is moving in that direction without any prodding from the outside. That should tell 'em everything they need to know.

Botton line:

Oracle or nothing, Office or nothing, anything or nothing will leave you screwed.

Re:Shouldn't they have thought of this earlier?

[plover]

That stops being true after a certain point. And it's no less true for $$$ware than OSS.

You think we roll out MS Office 2K without investing a couple man-years of effort, testing installations on supported platforms, building SMS packages, preparing training programs, advertising, providing conversion from Office '95 files, etc.? No difference between MS and GNU there.

And you may think that these are the big costs. Multiply that by 7,000+ desktops in this corporation, and Office 2K license fees run into the millions. If the installation cost runs to $150,000 for various peoples' time, it's still peanuts to the licenses.

John

OSS for the wrong reasons

[gentlewizard]

I'm not impressed that the CIO's in the article are using Open Source Software as a lever against the CSS companies.

Isn't that a little like making a date for the prom with the ugly girl, knowing full well that once you've made the cheerleader jealous, she'll go with you after all? Nobody cares about the ugly girl, she's just being used. And she'll be dumped in the end.

Seems to me this is the wrong reason to be considering open source. The CIO's want a brand name (cheerleader) and if they have to date OSS to get her, they will. But where does that leave OSS in the end?

Sfotware Bugs

[gnovos]

I know this is a great way to get flamed in the midst of a group of developers and programmers, but here goes: Why does software have to be buggy?

I have been writing software for years, and I can't understand this kind of "oh well, all software has bugs" mentality that exists in most of the places I have worked. When I write software, it *doesn't* have bugs. Sure, even a cautious design phase and well-documented specs won't help when you accidentally type "crsh++" instead of "cash++", but other than typographical errors (which can be easily found and fixed), there should be no *logical* bugs.

Personally, I begin to wonder how much of the bug issues these days are either because of sheer human laziness ("I don't need to check the limits on this array, no one will *ever* type in a 257 character string here") or because of intentionally releasing a flawed product ("Quick, slap an installer on version 0.0001733Alpha so we can sell it to Dell!"). Either way, as a programmer, I think it is a terrible thing...

If you are a programmer, and are reading this right now, take a few minutes after every block of code, go grab a cup of coffee, look out the window, read slashdot, something to take your mind off what you just wrote, and then come back to it, go through it line by line, make sure your code is doing what you think it is. Make sure there are no buffers to be overflowed and no shorts where there should be longs. Take pride in your work! Don't be a dime-paperback hack romance novelist! Be a Hemmingway, a Gibson, an Orwell, or whoever you think is a brilliant writer, be Tolkien! Give your programming work the same respect that you would reserve for those people you respect.

If programmers as a whole stopped thinking along the "bugs are inevitable" line and started taking a fresh approach, one where they think perfect, bug-free code is possible, then the software industry as a whole would become a much cleaner place.

No More Code Monkies!

Re:Sfotware Bugs

[CaseyB]

other than typographical errors (which can be easily found and fixed), there should be no *logical* bugs.

Congrats, you are the most perfect software developer to have ever walked the face of the earth. Either that, or you simply aren't experienced enough to know that all software has bugs. And when you get to the enterprise scale of software, developing good software is very, very hard. You need *good* (good == top 5%ile, based on my experience) coders, *good* architects, *good* testing and *good* project management. Getting any ONE of those is rare!

Take the Linux kernel. I think there's a pretty good bunch of smart people working on that. I think they care about the quality of their code. I think they appreciate correctness and elegance. And *every single version* of the kernel has had bugs. Why is that?

If programmers as a whole stopped thinking along the "bugs are inevitable" line ...

The average programmer should care more about the quality of his work. Duh. That's a feel-good tautology. It's not that easy.

Re:Sfotware Bugs

[Lumpy]

Please oh please add one more step..

Tight code.

Today it's easy to leave a kludge or do it in-efficently because I have 3098 teraflops or another insane amount of processing power.. so why waste my precious programmer time and make my code tight?

I believe every programmer should be forced to program for embedded systems... where if your code isnt tight, you're fired out of a cannon at a brick wall (man I miss that gerbil commercial)

Tight code that is bug-free is an ultra rarity today. no matter what OS you run.

Do we spend less time maintaining Linux?

[metoc]

Lets look at this in perspective?

Aside from paying M$ for licenses, is Linux in 2001 any easier to maintain?

If I installed 100 workstations in 2000 (all up to date software/patches/etc.) how easy would it be to maintain them. What if I wanted to install the latest version of Open Office? Would I need to upgrade KDE/Gnome, libraries, the kernel, etc?How easy would it be?

My experience is we spend most of our money on people to support the infrastructure, and things like licenses are small in the great scheme of things? Would I spend any less time maintaining and upgrading my Linux boxes?

Re:Do we spend less time maintaining Linux?

[Malcontent]

If you had a big box you could just install everything on that box. Then either mount the partitions or use run everything remotely with X. Choose a stripped down windowing system and it should be fine on a speedy network. When all else fails use apt or any one of a few dozen remote managemnt systems available for linux.

Proprietary Lock-in Not Addressed

[AT]

The argument of CIO is that cios will have more leverage over software companies with a subscription based payment model. Buggy software? Ok, cancel the subscription and go elsewhere.

The flaw here is that products like Oracle 11i (cited in the article) usual require a large amount of custom development work and intergration. It is also tightly coupled to Oracle's database. Since these products don't follow any standards (either they don't exist, or they are deliberately ignored to lock the customer), all that investment is lost by switching to a competitor.

All the software vendors have to do is to ensure the cost of switching to another product is higher than the subscription + the cost of living with the shortcomings of the product.

It is called proprietary lock-in, and it can take many forms -- business information in MS Word Documents throughout the enterprise, Oracle ERP that requires Oracle DB and custom development, and many many more.

Let's not be too quick to pat ourself on the back

[Junks Jerzey]

Having to upgrade is an awful, awful thing in many cases, I agree. But I don't think it can be fully pinned on Microsoft. Last year I upgraded my home machine from Windows 95 to Windows ME (which is really just Windows 98 + some extra junk that you can turn off). Then I found that my video card didn't have drivers that worked with Windows ME, so I had to buy a new video card. Who was to blame in this case? Not Microsoft.

The same sort of problem can easily happen with Windows and Linux. What if KDE 3.0 requires a 1GHz processor and 3D graphics card? What if the Star Office developers decide to change the file format and ignore backward compatibility, maybe because they are behind schedule and they can't find many programmers interested in helping out?

The Problem is Software is Too Cheap!

[west]

As I see it, the main problem with software quality control is that companies have to get product out by a certain deadline so that they can charge customers enough to stay in business. Remember, 99.9% of software houses are not raking in cash. Most make enough to stay in business, but there aren't a lot of Microsofts or Oracles out there.

If you are going to release bug free products, then you'll simply need to spend perhaps twice as much time, which means half us many new releases.

In other words, you've got to double the price.

Now, just how many CIO's aren't going to seriously consider switching vendors when a software house says they're doubling the price in order to get better quality control...

At least with subscription, the software house no longer has the desperate need to push a product out whether its ready or not.

Re:Software Bugs v. buggy software.

[dinotrac]

You put the question the right way: There should be no buggy software.

Buggy software is not the same thing as software that has bugs. Buggy software is software that reaches such a level of poor quality or irrational design that you identify it more by what it screws up than what it does. You may be able to get a lot done, but only because you've memorized a catalog of work-arounds and "don't do thats."

Any ambitious software will have bugs because people are not perfect, but buggy software exists because people don't give a damn.

Sendmail?

[cperciva]

They're quoting *Sendmail* as an example of well-written, bugfree code? Perhaps they count remote root holes as "remote server management" features?

Now if they said qmail on the other hand...

Encouraging yet frightening.

[fmaxwell]

While there is no shortage of shrill people claiming that open source is a software panacea, as a professional software engineer, I do not want to see it completely supplant commercial applications. I make my living developing software as do many of my friends. I don't want a world where I have to flip burgers or sell insurance during the day so that I can write, and give away, software at night.

I am not opposed to open source software. I use it as well as using commercial apps. When a vendor charges a fair price for a quality application, I have no problem with paying for it or recommending it to my clients. When open source is the best software for the job, I'm all in favor of using that. But I think it is morally reprehensible for a professional software engineer to go out of his/her way to avoid purchasing commercial software. If you earn your living by developing software, you should not deny your fellow software engineers payment for their efforts.

Open source software can be a valuable tool to keep commercial prices from spiralling out of control while quality takes a nose dive. I just hope that the commercial vendors wake up in time to keep open source from being the only choice.

Subscriptions Won't change anything...

[Black Art]

I have worked with Microsoft software for years. Every time there is a bug, I hear the same chant that it will be fixed "next version". Sometimes it is, but most times it is not. (And a bunch of new ones creep in in the mean time.)

A subscription model does not address one of the bigger problems that Microsoft (and many other companies) have.

These companies take orders from the Marketing department.

Instead of making stable products that work, you have programs that contain stacks and stacks of bullet items and features demanded by the Marketing department. (No matter how nasty it makes things for the programmers or the users.)

And these features rarely get removed.

The advantage with Open Source is that they are not stuck to "getting it out before Comdex or Christmas". The bugs get fixed. (For the most part. The reason Mozilla has so many problems is that it has a HUGE codebase. I am amazed that they can get a grasp on the project itself.) The drive for why a program gets written is different. Open Source programs are written to fill a use. (It may not be your use, but the programmer most likely needed it.) It is functionality driven, not buzzword driven.

Unfortunatly, most CIOs that I have met do not understand what it takes to implement their "solutions". They are not able to figure out that if you are locked in to a single vendor, with no options or abilities to "fix it yourself", if needs be, that the costs to productivity can be enormous.

It bothers me when a decision is made to go with a vendor and then you wind-up figuring out the true cost of what it will take to make it work. (Having to buy an extra license for this, and a license for that, and the extra BDC and PDC licenses, and the extra Exchange box so we can restore the mail spools that get corrupted every so often, and so on and so forth.) You start feeling like you have to keep forking out money just to keep your head above water.

And subscriptions will not make it any better. Instead, if you refuse to pay, then they can just shut you off. (Extortion-ware?) There is no incentive to fix anything. They have you locked in. The only advantage is for the company selling the software. They have a constant revenue stream. They no longer have to worry about "the next big version" to make their revenue for the year. They have a constant stream. There is no incentive to build a better product because you get the money whether or not there is anything new or useful.

And the beauty of the whole thing is that the customer does not own anything. With the current licenses, the company is absolved from any liablility whatsoever.

The customer is just there to pay and pay and pay.

This is the most lop-sided deal I have seen yet. (If UCITA ever gets enacted, you will have even less rights.) And there will be next to nothing you will be able to do about it. (Except for Open Source.)

"When you have them by the software, they're hearts and minds will follow." - B. Gates

ALL the advantages?

[schon]

This problem discussed in the article is better solved by the type of licensing model Microsoft plans to adopt: subscription software ... This way, you have all the advantages of open source

Umm, no I don't.

I don't have the advantage of actually having the source.

With open source, I can fix any bugs, without having to wait for the official fix (an advantage).

With open source, I can learn from the source code.

With open source, I can adapt the source for my own needs - like adding a feature I want that the vendor doesn't feel is necessary/important.

Software subscription gives you ONE of the advantages of open source, but there's no way it gives you ALL of the advantages.

How would OSS/FS apply to "enterprise apps?"

[BenboX]

I do not intend this as flamebait or troll, so please bear with me.

Successful Open Source solutions, I think, are general computing applications where the volunteer developers understand the standard requirements of the system in question. Namely, Open Source OS, databases, web servers, email servers, are successful because the developers can all agree on the critical features. They also would tend to agree on what "good solutions" to say, web server functionality, would constitute.

The examples of Lawson and Oracle 11i in question are so called "enterprise applications" or general business applications. Specifically, they discuss Financials & Accounting applications. Let's be clear here, this is not QuickBooks or MS Money level stuff. These are systems designed for "keeping the books" and billing and payments for multi-nationals, conforming to accounting regulations in the EU, Asia, US/North America, and the rest of the world.

My question is, how realistic is it to expect an Open Source solution for a global multinational financial app? Can I really expect the CPAs, international tax experts, the controllers and accountants (who normally make up part of the design team of these financial apps) to join in on the OSS design effort?

What about the other types of "enterprise apps," the manufacturing and resource planning software? The kind of software that, for example, Ford or GM might use to coordinate the sourcing and timing of components from Mexico/Thailand/Detroit? Vendors like SAP (and also Oracle 11i) include these components, designed by programmers, manufacturing shop floor professionals, and "industry expertise." It would be great if someone could prove me wrong, but I doubt Open Source is a viable option in these situations.

It's all a matter of design standards and requirements. Open Source developers know these backwards and forwards for operating systems, web servers, databases, and other general computing tools. When it comes to specialized business apps though, it gets real tricky. The OSS/FS options in these cases are simply not there.

Benbox

Subscriptions and migrating won't work

[Anonymous Coward]

Does anybody really believe they can work with a product for a two or three years, decide it's not working out and buy something different and somehow still save money? The cost associated with moving to new office suite alone can be huge (in a good sized company) not to mention what it would cost to move entire financial, ERP or email systems.

If they need bug free, no problem! Any decent team of software engineers can create rock solid, bug free code. We simply adopt the same design and manufacturing standards that a company like Boeing has. Sure, it may take years for a word processor to be developed and it'll cost about $250,000 dollars but it will only crash your system about as often as a 747 crashes too. Everyone's happy right?

Wrong! These CIO's say they want bug free but what they aren't saying is they don't want the price to go up at the same time. The extensive testing, debugging, improved up front design work, etc will cost a lot of money and increase the time it takes to get an application out the door as well as it's price tag. Who's going to pay $1000's of dollars for something that's rock solid when they can get it for $100 even though it crashes once a day or has some extra configuration issues that have to be resolved?

There'll be a few that will but if Microsoft has proven anything it that good enough IS good enough. That's how they got their monopoly, by getting the same CIO's to look only at the bottom line and pay modest fee for crappy software.

These guys know it's not good but try convincing the bean counters to spend $1000 for something they can get for $100. Business types can rarely accept the loss of productivity cost associated with the occasional reboot or restart of an application.

Requirements

[Xenu]

I don't care if you are the best programmer on the Earth and every program you write has a formal proof of correctness, you will still get bitten by incomplete and/or incorrect requirements.

Re:Software Bugs v. buggy software.

[michael_cain]

And don't forget the number of times that a piece of code has been patched (often badly) over its life. Most developers who do maintenance can easily come up with an example of a function that started out accepting three parameters and doing something straightforward with them. Now it accepts seven, and is so full of nested if-else stuff to handle all of the special cases that it's almost impossible to figure out what's really happening.

I had a friend who used to say that one problem for software developers is that, unlike hardware, the "white wires" where software has been patched don't show. Continuing his analogy, no company would ship a circuit board that had a dozen cut traces, two dozen white wires, ICs with half the pins cut off and three daughter cards soldered on in odd places. Software with the equivalent level of kruft ships all the time.

Cost of Retaining Programmers to Provide the Suppo

[egburr]

I've read a lot of comments about how companies are callously refusing to support older products because they have newer versions available and insist that you upgrade to the newer version. That they're only doing this to make more money.

That's not entirely true. One big consideration in all this is that to provide support for the older products, they must retain programmers who know those older products. They must pay these people to sit around and wait for a support request to come in. If the volume of incoming calls is low, how do you justify hanging on to these people?

You find them something else to do. Probably, since they are intimately familiar with the product, you assign them to working on the new version. When support requests start coming in for the new version, who are you going to turn to? The people who worked on it.

So, now you have these people supporting both the new and old versions. As call volume increases for the new version, which has priority, the old or the new?

At some point, these people are going to lose skills in the old version because of spending so much time with the new version. At some point, you are going to have to decide to drop support of the old version unless someone is willing to pay an exorbitant fee so you can justify retaining and/or training people to provide support for the old version.

This is true for both usage and bug/defect support.

This is where Open Source really makes a difference. How often does a company release the source code to their software, even after they have decided it's no longer commercially feasible to continue providing support for it? With Open Source software, if you can't find someone to support the software, you can hire and train someone to do it for your company. You have the source code available; you can fix it yourself.

One way or another, you're paying for the support. The difference is who has access to the source, and if they decide whether it is worth their time to support it.

Withholding payment would do miracles (argh).

[SysKoll]

The article has a section titled "Withholding Payment: The Brute Force Option". Well, that would really do miracles for solving many QA-related problems. I know. Been there, done that.

Scene: The year is 1992. A computer manufacturer has sold a big mainframe to a local bank. There is a glitch somewhere in the interface between a network driver and a particular model of ATM machine. Nobody cares except of course the bank. No resource is available nowhere to debug the problem. Nobody want to pay for it.

So the bank's boss holds a meeting and tells the computer manufacturer that he will suspend payments on the mainframe until said mainframe could talk to the ATM as promised. The cost of the mainframe: a few millions. The look on the sales guys: Priceless. :-)

It took only a few calls ("he suspended WHAT???") to suddenly find the required resources. Mysteriously, money appeared to send people (me!) and debug the problem. Of course, the manufacturer could have sued the customer, but I am not sure it would have been a smart move. Satisfied customers are nice to have, ya know.

That's why I really think this article is an excellent thing. A Revolt of the CEOs is the only thing that can prevent (some) software to be delivered with swarms of bugs on purpose. It's one more step toward making software a science instead of a black art.

And if this revolt could tip the balance towards open source, so much the better.

Here is a slightly more elegant proposal: Network providers have a garanteed uptime. If your leased line or fiber drops below a certain minimum uptime, the provider starts refunding you. That's a standard clause.

How about suggesting such clauses to CEOs for their critical systems?

This is what I hope we will finally start hearing: "We replaced Sendmail with Exchange. Since then, I barely get any email and MS is paying us." Hmmm.

-- SysKoll

It's not about the cost of the software...

[rcs1000]

Anyone who has spent $100,000+ on a piece of software knows that is NOT the real cost. What you pay Lawson, Oracle or SAP is a mere fraction of the total cost.

An SAP salesman told me that the ratio of license to total cost was 1:8. That's right, they paid $8 in services (implementation/integration) and customisation for every $1 in licenses.

And that's why 'subscriptions' don't work. So, you pay Oracle a fee each year. Great. Changing the system is still prohibitively expensive because implementing a new system is far more expensive than just paying a new subscription fee.

Nor does open source help. (Much). Software that automates business processes is generally designed by people that work (and know) the relevent industries really well. It is a business not a technical issue. These people generally don't want to share their knowledge with their competitors. Or at least not without stock options .

CIOs and the like need to concentrate on:

(a) Getting software vendors to take some degree of responsibility for systems. (Success fees are a good idea.)

(b) Defining exact needs from the start. How many software projects start with... 'i think i know what i want but i'm sure i'll work it out as the project goes on'?

*r