Anyone else have a problem with this?

[PaulG.]

On a post from Info-LabVIEW I read something disturbing. Then I looked it up myself. From this page:

"... LabVIEW 2009 Service Pack 1 software represents more than 3,000 hours of engineering time and addresses nearly 100 bugs in LabVIEW 2009 ... Only customers with active SSP membership at the time of release (February 15, 2010) will be able to activate LabVIEW 2009 Service Pack 1 and the latest versions of the modules...."

What could possibly motivate NI to charge us money to fix their bugs?

Stop writing crappy code, NI. Fix it before you ship it. I can imagine how buggy 2010 is going to be.

[george seifert]

Agreed. I'm on the SSP plan, but I think it stinks to charge for bug fixes.

And are we supposed to be impressed that it took 3000 hours to fix the bugs?

George

[crelf]

Stop writing crappy code, NI.

I'm not going to argue about the SSP, but I do take exception with "Stop writing crappy code" <- NI's code isn't crappy. In fact, it's of an excellent standard. The problem is that LabVIEW (and all the associated toolkits) contains millions of lines of code, and they can't (and IMHO shouldn't) test every single line of it for every single permutation - that's just not possible. They use a different strategy: the beta programme, where the average Joe can find out if what NI's thinking of releasing will work for what they want - their own use cases. In short, if you want better code (ie: code that works for your specific use case(s)) then test it within the beta programme.

[jzoller]

Funny thing is, if they ship me a bad hardware card, or PXI chassis, they replace it for free.

This has left me with a bad taste for years.

Joe Z.

[Grampa_of_Oliva_n_Eden]

I'm not going to argue about the SSP, but I do take exception with "Stop writing crappy code" <- NI's code isn't crappy. In fact, it's of an excellent standard. The problem is that LabVIEW (and all the associated toolkits) contains millions of lines of code, and they can't (and IMHO shouldn't) test every single line of it for every single permutation - that's just not possible. They use a different strategy: the beta programme, where the average Joe can find out if what NI's thinking of releasing will work for what they want - their own use cases. In short, if you want better code (ie: code that works for your specific use case(s)) then test it within the beta programme.

The voluntary Beta Program can be improved in a couple of simple ways.

1) Change the EULA that comes with the Beta to back us up if the Beta testing goes sour on us. If I try out a Beta and it steps on my machine (renders the official releases inoperative) then one of the tools I use to make a living (my mahcine) is jeopardized and according to the EULA "Tough luck Ben!". This translates as "Wait until you retire." for me so I am out of Beta test cycle on those grounds alone.

2) Use the Bug Report records to find the people that have found and reported the most bugs and offer them a resonable rate to use BETA code (with full support if something goes wrong after codding for a moth or so) in there every day work.

Since neither of the two items above apply to the BETA, I wait for the "dot-zero" version where I do have support and my boss does pay me to use it and will not fire me if I do. As I find the bugs I report them. So until there is a serious change in the policies this situation will not change.

Now for what may be a retorical or just a philosophical Q

What other industry can expect serious product testing by people that are volunteers?

Just my 2 cents,

Ben

[crelf]

Now for what may be a retorical or just a philosophical Q

What other industry can expect serious product testing by people that are volunteers?

There's something I totally agree on - I think if there's to be a serious beta, then we'd need to run it in parallel with an already released version on a real project - that's where we'd find the majority of bugs. That said, my guess is that NI's already done an FMEA or the like on this process and are comfortable with the current methodology. Anyway, I didn't mean to hijack this thread with a beta schism - my point was that I didn't agree that I writes "crappy" code per se - we all live and code in the real world, and I think that labelling NI's code as "crappy" is unfair.

Besides, if you seriously think that NI's code has had a negative impact on your business, then give your local FSE a call and they might be able to help you. NI isn't a faceless corporation, and they're not out to screw you with bad product.

[Antoine Chalons]

Fix it before you ship it.

I understand the frustration of having to pay for a bug fixing version.

But to be fair I don't think NI (or any other company that ships such a big soft) can wait until the product is 100% bug free. If you want LabVIEW 2010 to be released only when it has no bug at all it will be released in 2020. Big soft are released not when they are bug free, but when the market needs the new feature they bring. It's always been like that, if you want to take advantage of the new features you also have to cope with the new bugs.

That's for shipping a version that still has bugs.

That said, charging for a bug fixing version... well... if you were happy until then with LV2009, maybe you don't need to get the upgrade :-o

[PaulG.]

I'm not going to argue about the SSP, but I do take exception with "Stop writing crappy code" <- NI's code isn't crappy.

I don't think I've ever said that NI's code was crappy before today.

100 bugs that take 3000 manhours to fix is crappy code. I think NI's push to get a new revision out every year is making their quality suffer. Code that has that many bugs and took that long to correct did not spend enough time in Beta testing.

[crelf]

100 bugs that take 3000 manhours to fix is crappy code.

Depends on how complex or entreched the bugs are I guess... I've had bugs to fix that took between a few minutes and a few months, although a few minutes is rare since I usually need to do a lot of validation afterwards (including re-checking things that the bugfix may have affected), so I don't think code fixes based on 30 hours per bug can be called good or bad - it is what it is.

[ASTDan]

100 bugs that take 3000 manhours to fix is crappy code.

I have found bugs that in order to fix them I have to re-architect some of my code (taking many hours).

Also, with experience and new knowledge I have learned better, more effective ways of doing things. I am sure NI, like all human beings are continually evolving.

In a perfect world it sucks to pay for bugs fixes. That being said I think we would all go broke if nobody paid us to fix ours or somebody elses mistakes. Trying to minimize bugs I think is very good practice but to expect a bug free product without expecting to pay big bucks and I don't think is practical.

Good, Fast, Cheep

Pick 2

My $0.02

[NI_Eagle]

This is Jeff Phillips, one of the LabVIEW Product Marketing Managers. I just wanted to take a moment to clarify a few things:

First, if NI comes across a bug that is critical, our policy is to release a public patch for LabVIEW that is available to everyone.

Second, we've been down the path of delivering the "maintenance release" as a true fix for LabVIEW, meaning you install it on top of the original version. In order to improve the user experience, we switched the Service Pack to a stand-alone version, which means that activation separates who can and cannot use it.

Third, the price that you are paying for SSP includes a lot more than just the bug fix version. As mentioned before, you also receive a new version of LabVIEW each August, followed by a service pack containing bug fixes for that version, along with support from Applications Engineers, and access to specialized training content through the NI Services Resource Center.

Anyone who purchases LabVIEW 2009 is entitled to that version, the following Service Pack release, and the release the following year (i.e. LabVIEW 2010). If your service lapsed between the release of 2009 and the release of the Service Pack, then that means that you received LabVIEW 2009 as part of your previous service (at a MUCH discounted rate compared to a true upgrade).

Our goal in switching to a subscription-based service was to make it possible for us to integrate feedback and fix bugs more easily and frequently. Having a yearly release cycle allows us to introduce new features more frequently, while mitigating the risk associated with introducing those features into a stable code base.

Respectfully,

Jeff

[smenjoulet]

Stop writing crappy code, NI. Fix it before you ship it.

As Chris and others have noted, I think that is an unfair characterization. I think this born more out of anger at the SP1 terms than of the general bugginess of 2009. It is my anecdotal experience that the quality of NI software has generally improved over the years. There have been hiccups here and there, but I find LabVIEW, etc. more stable than in the earlier years.

What could possibly motivate NI to charge us money to fix their bugs?

Agreed. I'm on the SSP plan, but I think it stinks to charge for bug fixes.

Let me preface my following comments by saying that I don't agree with NI's verbiage on SP1 nor am I trying to defened them. I am just trying view it from the opposite side to understand the motivation. Let the flames fly.

On the requirement of an active SSP for using SP1:

Stop for a moment. I think it affects relativley few LabVIEW users. If it does happen to affect you, that is little consolation. But you might need to adjust your "upgrade" practices. Let me explain:

1) If you purchased 2009, then you have 1 year SSP built-in. No charge for bug fixes.

2) If you buy the upgrade to 2009 from an earler version, ditto above.

3) If you have an active SSP (per SP1 terms) there is no charge.

4) If you are not using 2009, you're not affected.

The only users it would affect are those that had an existing SSP (ealier LV version, Dev Suite or VLA) and let it expire between the release of LV2009 and the release of SP1, but they used that SSP to upgrade to 2009 before the expiration. If you are upgrading to a new version, you might want to question the practice of letting SSP expire. Everyone else should be covered. Like I said at the beginning, I don't agree with terms, but if affects few users and those it does affect had a choice.

On the motivation of NI to adopt these terms:

I think it comes down to users getting up to two years of SSP for the price of one. Take the following example:

I purchase LV8.6 in Oct 2008. I get my 1 year of SSP. I get the 8.6.1 maintenance release. NI releases LV2009 in August 2009. I upgrade to LV2009 in September. I let my SSP expire in October 2009. I get 2009f2 and f3 fixes. NI releases LV2009 SP1 to active SSP users only. I am "locked out" of the additional bug fixes by not keeping SSP active. But if NI let me have access to SP1, I'd be getting a year and a half of SSP (minus the priority phone support). That could extend close to 2 years if they have additional fixes come out.

I'm not defending these terms, just offering up this viewpoint for you to chew on and spit out as you wish. If you disagree with NI, make your voice and case known.

[EDIT] Jeff Phillips has made some additional eloquent arguments from the NI side above.

Besides, if you seriously think that NI's code has had a negative impact on your business, then give your local FSE a call and they might be able to help you. NI isn't a faceless corporation, and they're not out to screw you with bad product.

I second that 100%. If you have a good a DSM/FSE then work with them. Have the above discussions with them and raise the issue. I've usually found them willing to do whatever is reasonable to help out.

-Scott

[John Lokanis]

I thought a new version of LV always came with one free year of SSP? So, the service pack should be free for anyone who bought a copy of LV2009, right?

And for those of us who maintain SSP, it is free anyways (or at least covered by the SSP fees)

Maybe the student edition of LV does not come with the 1 year of SSP, but checking the NI web site, the base, full, pro and dev suite versions all include one year of SSP in their price.

So, who is actually paying for this service pack? Anyone?

[Grampa_of_Oliva_n_Eden]

I thought a new version of LV always came with one free year of SSP? So, the service pack should be free for anyone who bought a copy of LV2009, right?

And for those of us who maintain SSP, it is free anyways (or at least covered by the SSP fees)

Maybe the student edition of LV does not come with the 1 year of SSP, but checking the NI web site, the base, full, pro and dev suite versions all include one year of SSP in their price.

So, who is actually paying for this service pack? Anyone?

I have customer that had to drop the SSP due to budget reasons besides they were running of closet space for all of the update disks that were not installed) and then latter needed to upgrade. Rather than buy a new license NI let them pay for the SSP on their old license (or something like that). In my experience Ni has always given the customer the best possible options.

Ben

[crelf]

I thought a new version of LV always came with one free year of SSP? So, the service pack should be free for anyone who bought a copy of LV2009, right?... So, who is actually paying for this service pack? Anyone?

That's a really good point - if you've got LabVIEW 2009 and don't have an SSP then you somehow got around the system. Therefore, this issue shouldn't be effecting anyone...

[Grampa_of_Oliva_n_Eden]

That's a really good point - if you've got LabVIEW 2009 and don't have an SSP then you somehow got around the system. Therefore, this issue shouldn't be effecting anyone...

Its possible to purchase a license without the SSP. A couple of weeks ago a customer wanted to clone an app certified by the FAA that was in LV 7.0. They purchased teh license for LV 2009 so they could leaglly install LV 7. In that case the SSp did not make any sense for them.

Ben

[crelf]

Its possible to purchase a license without the SSP. A couple of weeks ago a customer wanted to clone an app certified by the FAA that was in LV 7.0. They purchased teh license for LV 2009 so they could leaglly install LV 7. In that case the SSp did not make any sense for them.

But is that an edge case? My understanding was that you can only drop the SSP under special circumstances - it's not just a matter of unclicking a checkbox on NI's wbesite.

PS: SSP might still make sense to them - as Jeff said, there's more than just bugfixes in an SSP

[jzoller]

This is Jeff Phillips, one of the LabVIEW Product Marketing Managers. I just wanted to take a moment to clarify a few things:

...

Anyone who purchases LabVIEW 2009 is entitled to that version, the following Service Pack release, and the release the following year (i.e. LabVIEW 2010). If your service lapsed between the release of 2009 and the release of the Service Pack, then that means that you received LabVIEW 2009 as part of your previous service (at a MUCH discounted rate compared to a true upgrade).

...

Respectfully,

Jeff

The above "release the following year" is how you end up without the SSP for the bug fixes.

I think this gets away from the point, though.

If I release code to a customer, the bug fixes are priced in. If they come back to me in two years and say "Hey, we found a bug that matters to us", I'm going to fix it for them, gratis (and have done so). I consider it to be what professionals do.

In the past, NI has released features and bug fixes commingled. Not so much, this time around, but the SSP rules haven't changed.

Personally, I would prefer to buy a single version of LV and get all bug fixes for that version free forever, rather than getting the cheap upgrade the next year.

Joe Z.

Edited March 1, 2010 by jzoller

[NI_Eagle]

The above "release the following year" is how you end up without the SSP for the bug fixes.

I think this gets away from the point, though.

If I release code to a customer, the bug fixes are priced in. If they come back to me in two years and say "Hey, we found a bug that matters to us", I'm going to fix it for them, gratis (and have done so). I consider it to be what professionals do.

In the past, NI has released features and bug fixes commingled. Not so much, this time around, but the SSP rules haven't changed.

Personally, I would prefer to buy a single version of LV and get all bug fixes for that version free forever, rather than getting the cheap upgrade the next year.

Joe Z.

Joe,

To your point of buying a single version of LabVIEW and getting bug fixes for that version free, that was the intent of SSP. Take the following case:

1. You bought LabVIEW 8.6 in September of 2008
2. In March 2009, you received LabVIEW 8.6.1
3. In August 2009, you received LabVIEW 2009
4. March 2010 rolls around, and LabVIEW 2009 Service Pack 1 releases

At this point, all you have to pay is for the renewal of your service. Each year, you pay one renewal price, and that gives you the August release and the following Service Pack. In your scenario, you would have to pay a significantly larger upgrade price each time LabVIEW is released. If you want each version and the bug fixes, then the SSP model is much more cost-effective for you. Really, it is more cost-effective to stay current on SSP and only upgrade your version of LabVIEW once every 3 years than it is to pay the upgrade price for LabVIEW every three years. You also keep the support and training resources through that time.

Respectfully,

Jeff

[crelf]

If I release code to a customer, the bug fixes are priced in. If they come back to me in two years and say "Hey, we found a bug that matters to us", I'm going to fix it for them, gratis (and have done so). I consider it to be what professionals do.

Well, that's not the only professional model There's also the model where you have well defined and signed off requirements, and if the system meets those requirements (traceably through and acceptance test proceedure) then it's done. Then, if the customer comes back a couple of years later and complains about bugs, what they're actually complaining about is out-of-scope features.

Of course, it's never quite as black and white as that, but I just wanted to point out that not fixing "bugs" after delivery doesn't necessarily mean that your not professional. In fact, the model I mentioned is what most regulated industry customers expect and insist upon.

[jzoller]

Jeff: For the record, I strongly recommend the SSP for anyone who can manage it. I still don't agree with charging for bug fixes, particularly now that it's technically feasible to separate them from new content.

Chris: Bespoke software and off-the-shelf software are pretty different models... (NI isn't letting you spec out LV, is it? If so, where do I apply!?)

I'm content to remain discontent on the subject... NI will do what they do.

P.S. For some more opinions on the matter, check out: http://stackoverflow.com/questions/426319/should-you-charge-a-customer-for-bug-fixes

Joe Z.

[John Lokanis]

I still don't see any way anyone is actually paying for SP1. If you are, can you tell us how that happened?

[crelf]

Chris: Bespoke software and off-the-shelf software are pretty different models...

That is my point exactly - don't assume that your model is the only professional model, and there are reasons that people use other models.

...and I agree that you shouldn't charge for bugfixes - as long as that's what they are. In the model I mentioned, they're only bugs until they get past the SAT. After that, they're feature requests.

[PaulG.]

I still don't see any way anyone is actually paying for SP1. If you are, can you tell us how that happened?

Excellent point. Maybe we (me) are getting a little too upset over something that rarely actually happens, i.e. paying for LV bug fixes.

I think it was the way it was worded on the NI page in my original post. To paraphrase the way I understood it: "We spent 3000 man hours fixing 100 bugs but YOU have to pay for it ..."

(sigh)

[smenjoulet]

I still don't see any way anyone is actually paying for SP1. If you are, can you tell us how that happened?

While I'm not in this situation, I can envision a rare one. Both Jeff Phillips and I posted this scenario in our previous posts:

1) Buy LabVIEW 8.6 in October 2008 (get one year of SSP)

2) Get all 8.6 bug and maintenance releases.

3) Under SSP, you upgrade to LV2009 when NI releases it in August 2009.

4) You do not renew SSP in October 2009

5) You still get the 2009f2 and f3 fixes, but not SP1 as your SSP has expired

At that point you are not required to "pay" for SP1 if you don't feel you need, but you also can't install it. But if you do you need it, you would need to "pay" for it by renewing the SSP on your license. The cost for that varies by how long your license has been inactive.

Whether you interpret that as actually paying for SP1 or paying to renew your SSP (and getting SP1 as one of the benefits) is up to the indivdual. Like I said, I think that situation would be pretty rare.

-Scott