Jump to content

crelf

Members
  • Posts

    5,759
  • Joined

  • Last visited

  • Days Won

    55

Posts posted by crelf

  1. flaws in the competion's quality?

    Speaking of which, can anyone remember when the definition of the word "quality" changed from "it's a good product" to "it's an exact duplicate of the previous one"? The ISO quality standard is about that something is guaranteed to be made to a spec and a process, not about whether it's something that is function or will last. It seems that there's more concentration these days on verification, yet little on validation. Or, at least, some companies seem to interpret validation only as it applies to verification.

    So when a car company spouts about how their quality is high, they're not saying that their cars are good or that they will last a long time - they're saying that they're all made to spec. So, if that spec has a flaw in it (eg: accelerator pedals sticking), as long as they all have that fault, then it's still a high quality product. Yet I'd suggest that the common person that their advertising is aimed at doesn't understand this subtlety.

    More info here: http://en.wikipedia.org/wiki/V%26V

    Meh, maybe it's just me.

  2. Did you know Toyota's expected loss is around $7.7US billion dollars? Just this quarter? It's their first loss in 70 years. Think how much they could have saved, had they fixed their "bug" in timely fashion.

    Well... yes and no. I find it interesting that the Toyota issue is being made much more of an issue here in the US than anywhere else in the world. Maybe it's because I'm in Detroit and it seems that Toyota pretty much all the local media can talk about right now. Perhaps a nod to the big three?

    Do you sell products, or do you sell reputation? Reputation is worth a lot more.

    But you can't have one without the other smile.gif

  3. I don't think there's much extra work implementing in VISA than raw GPIB, so I'd go for VISA. That's said, it's been a while since I've used raw GPIB. Also, there are a handful of oddities with each physical layer, so your application *might* require you to use GPIB only, but those oddities are very very rare, and VISA does have GPIB-specific properties, so you should be good.

    • Like 1
  4. LVOOP is by-value, just like almost everything else in LabVIEW, so don't think of it like "how do I access objects across parallel loops", instead think of it as "how do I acess <anything> across parallel loops".

    LVOOP is by-value, just like almost everything else in LabVIEW, so don't think of it like "how do I access objects across parallel loops", instead think of it as "how do I acess <anything> across parallel loops".

    ...just noticed that Aristos already answered the question better than me :)

  5. What mind maps are. I've played around with FreeMind a little, and have a hard time seeing how this will be worth the effort. Am I missing something? Wrong software? Forget software, do it by hand? Just a few more hours to get past the bump in the learning curve and see how wonderful this stuff is?

    I think they're useful for high-level conceptual designs and also good for brain-storming sessions. That said, they're easily overused, so draw a line in the sand on when/where you want to use them, and where other tools are more appropriate. We use Mindjet MindManager.

  6. 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 ..."

    Yeah - I agree that the wording on that webpage should be a little better than it currently is. At least the bugfix and SSP sentances could be spaced much further apart...

    • Like 1
  7. 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.

  8. 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.

  9. 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 :)

  10. 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...

  11. 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.

  12. 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.

  13. 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.

  14. LAVA is looking for a handful of people to help us clear off the shackles of LAVA 1.0 so we can move forward more easily with 2.0. If you've got a few spare minutes every now and then (think, while having a morning cup of joe, over lunch, sitting on the can - okay, maybe don't actually *think* about sitting on the can) then we could really use your help. We've been slowly migrating the old LAVA 1.0 content to the new site, but the progress it going more slowly than we'd expected. So we'd like your help.

    All we need is a few minutes each day over the next couple of months or so to get all the content from the LAVA 1.0 placeholder subforum to appropriate places in the LAVA 2.0 forums. You will have elevated privileges for the time it takes to move all the old content. There are no prizes for those who move the most, but we'll post the usernames of those who volunteer to help out and heap steaming piles of praise on you, and you'll have the warm glow of accomplishment in helping out your community to boot.

    Our aim is to have the old subforum empty and offline by the end of April, and there are about 9,000 threads to be moved, so it's a pretty ambitious task, but we think that, with the right people, we can get it done.

    If you're interested in helping out, please PM me here.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.