LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
TiTou

Give discounts on Developer Suite based on the number of unresolved CARs

Status: New

Say a 1% discount on the annual DSRL fee for each unresolved CAR per company/organisation.

If you think 1% is too much, please suggest a percentage that you think would be acceptable.

 

If NI did this it would really show how much they care about the quality of their products and also that they value the feedback of their users.

 

It would also be an incentive for users to report issues and for R&D to fix them.


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

5 Comments
altenbach
Knight of NI

I guess you are talking about just the unique and new CARs reported by that specific company.

 

(I am sure there are over 100 CARs overall, so should everybody get everything for free? Probably not. :D)

 

How about if the company still choses to use an old version, but the CAR has been fixed in a newer version?

 

One problem I see is that there could a chilling effect, such that it would take more effort to actually generate a CAR or that they get dismissed as "not a bug" more quickly. There should also be a graded scale such that a reproducible BSOD is rated more highly compared to a missing punctuation on some obscure help page. 😄

 

I think rewards should be personal, not per company. NI could implement a bug bounty program, offering t-shirts, NI-Week discounts, and other rewards. (See also).

 

(If they would offer cash rewards, I would be a multi-millionaire by now!  Just kidding! :D)

TiTou
Trusted Enthusiast
Of course, with what I had in mind it was a "per company" unresolved CAR count, and wether you're using the latest version or not doesn't matter ; if the CAR has been felt with (whatever the version) it goes out of your count. I did think of the chilling effect, AKA getting R&D to say "yep, this is a bug, here is your CAR" would be a lot more difficult, but that is like thinking NI folks are shameless sneaky and dishonest. I don't want anyone to believe that I think that way. I love the bug bounty program idea! I don't like T-shirts, mugs, clips & other gizmos. IMO discounts on NIWeeks or certification exams or things like that are much more valuable both for NI and their users.

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

AristosQueue (NI)
NI Employee (retired)

THIS POST IS SPEAKING FOR MYSELF; I AM NOT SPEAKING FOR NATIONAL INSTRUMENTS. I have not discussed any such policy with my management or other developers. This is strictly my take on software bug bounties and why I do not think NI is a good fit for them. Others within NI may disagree. Heck, the vast majority of NI might agree or might overwhelmingly disagree -- as I said, I haven't asked.

 

> but that is like thinking NI folks are shameless sneaky and dishonest

 

Not sneaky and dishonest, but any judge who has a stake in the judgement has a harder time maintaining objectivity, and over time, too much exposure to conflicting interests does lead to dishonesty in aggregate. You should always be suspicious of the effect any program has where it incentivizes bad behavior. You need empowered, independent regulatory bodies to monitor such situations.  Sometimes those regulatory bodies can be inside the corp, one subsection monitoring another, and sometimes they need to be outside the corp. This is for any type of regulation in a corporate environment. Bug bounties are no exception.

 

I support bug bounties for certain types of bugs, but not for most kinds of bugs. Security bugs, for example, are something I support at most companies. For NI, I'd support bounty for math errors in our run time libraries. More on that later. Both of these are very specific areas of code for bounties.

 

Why do I oppose bounties for most bugs? There are two reasons to impose a bug bounty.

 

The first possible reason is to motivate the developers with the stick of decreased wages\bonuses. This presumes that we do not already work to the best of our abilities and need additional motivation. This presumes that the level of bug fixes would somehow increase if a bounty were hanging over our heads for every release. We already have a strong, personal incentive to ship as quality a product as we can. The marketplace reacts very badly if our quality bar falls too low, and features that are overly buggy can easily be traced back to the individual developers involved. I simply don't believe that we would fix a single CAR more than we do today if there were a general bug bounty in place. 

 

The second possible reason is to motivate users with the carrot of testing edge and corner cases. There are sections of code that are unrealistic to test in-house. Security is the prime example. You can study a block of code until you're blue in the face for security holes, but having the million users all pound on that one algorithm in the hopes of a reward is a far better test. Bounties provide a way to entice the world's security experts, who you cannot aford to actually hire most of the time, spend a few hours on your code. For a section of code that a company wants to be extrordinarily robust, then a bounty is worth it.

 

BUT -- and this is big -- remember under reason 1 that I said I doubt we would fix a single extra CAR. What a bounty in a given area would probably do is shift the CARs we do fix to a particular area, leaving others less refined. If we're paying to get examination of the edge and corner cases, we're probably going to fix them, leaving less time for other bug fixes.

 

A security fault, once discovered, can, in days (hours), compromise an entire industry. It is worth it to find those ahead of time, with as much aggressive testing as possible. That's why those are worth bounties. Other bugs, even egregious crashes, may bring down a single customer, but doesn't generally lead to wider problems across industry. Those CARs can escalate and be dealt with.

 

Proving out every corner case of the compiler or editor or UI  is a nice-to-have. I'd love it if we could have a bug-free environment. But the cost of such bug-free software is exhorbitant -- witness the cost of medical and military apps that do have to meet that bar. Expending captial on bug bounties for areas where you cannot afford to sweep every corner is foolish for any corporation -- you would be paying people to aggressively test an area of the code where you lack the resources to maintain that code completely bug free.

 

The reason that I'd support a math bounty is that it is near the core of NI's business, and they are the kind of errors that people might not even realize their software is making. Diagnosing a math library error can be impossible for people who don't know the computations. And our software in that area is robust already, so hitting it from every angle would not churn up so many CARs as to starve other parts of LabVIEW.

 

Basically, I don't think most software companies need a stick to drive developers. To me, the only use for the carrot for users is in those areas that are a company's primary focus, where the drive for a bug-free implementation makes the bug bounty a source of pride instead of a source of despair.

JÞB
Knight of NI

And that is a feature lacking on the IE.  Stephen said it very well!  NI attempts to produce a "Bug Free" IDE but then, there are the darned users! 

 

Who would have thought that a simple find and replace operation would generate a cosmetic feature? "Smart Probes" loosing their brains when undocked? Bookmark managers going insane with unmake space?

 

MOST, if not all of those features are developer only seen! As a developer, I like my code too look clean and behave correctly.  Correct behavior! has seldom been a problem.  

 

@NI! of course we would like to see "Featureless code"  If you know of a developer who writes some I'd like the resume.


"Should be" isn't "Is" -Jay
MichaelAivaliotis
Active Participant

The title of this post made me LOL.



Michael Aivaliotis
VI Shots LLC