Ideas on LV Idea Exchange have started moving to "In Development"

[Aristos Queue]

If you want to check out the current list of "in development" ideas, click here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/indevelopment/tab/most-kudoed

This will pull up a list of ideas filtered to those with status set to "In Development". The list is short this year -- please remember what NI folks have said since the NI Week keynote: LV 2011 is going to be a stability and performance focused release. Even though only a few new features are going in, the ones that made the cut are going to put a smile on a few faces. I know that I'm already enjoying that on my development box I can -- wait for it -- save and then undo! Applause for the pair of really bright developers who figured out that little trick. Anyway, take a look -- there's something in there for everyone.

[jgcode]

If you want to check out the current list of "in development" ideas, click here:

http://forums.ni.com...tab/most-kudoed

This will pull up a list of ideas filtered to those with status set to "In Development". The list is short this year -- please remember what NI folks have said since the NI Week keynote: LV 2011 is going to be a stability and performance focused release. Even though only a few new features are going in, the ones that made the cut are going to put a smile on a few faces. I know that I'm already enjoying that on my development box I can -- wait for it -- save and then undo! Applause for the pair of really bright developers who figured out that little trick. Anyway, take a look -- there's something in there for everyone.

Thanks for posting.

I see your lobbying (Edit .> Create) paid off - so you too must have a smile

[crelf]

I don't think that the list is small at all - I think it's excellent (and not just because one of my ideas is on it )

[jgcode]

hmmm, how did the Save-->Undo option make it in with only 64 kudos and 3 comments...

IMHO I think it got in for coolness and convenience.

I just voted it up, as I missed that one.

it is something that e.g. Microsoft Word can do, so I figured LabVIEW should be able to do it.

Sure know I could have used it a few times already

[Michael Aivaliotis]

Some more status links here.

IMHO I think it got in for coolness and convenience.

I just voted it up, as I missed that one.

it is something that e.g. Microsoft Word can do, so I figured LabVIEW should be able to do it.

Sure know I could have used it a few times already

I agree this is a great feature to have.

[Aristos Queue]

hmmm, how did the Save-->Undo option make it in with only 64 kudos and 3 comments...

I call shenanigans!

I think we can all agree that we could easily drum up kudos for that idea as we did with the Create SubVI idea -- making save work after undo has years of customer requests behind it that predate the Idea Exchange.... call it "historical Kudos." :-)

[Black Pearl]

The count of ideas is 10. Taking into account that this is meant to be a feature-small release and 2010 had 14 ideas implemented (?), it's not bad...

Also looking at 'Completed'=48: this number will rise by 20%.

Felix

[Cat]

Excellent! Both the stability part and the choices for development in LV 2011.

[ShaunR]

What exactly is meant by "stability release" anyway?

Can we expect that it won't require patches?

Can we expect all previously reported bugs to be fixed?

Do we have to pay for a more stable environment?

What is the difference between a "stability release" and a "patch"?

[JackDunaway]

hmmm, how did the Save-->Undo option make it in with only 64 kudos and 3 comments...

I'll be the first to admit: NumVotes is often not proportional to IdeaPowerOrUsefulness. Distributed Wires=356 versus Undo after Save=67 is a great example. I'm excited Distribute Wires is making it into the 2011 release, don't get me wrong, but it comes with the opportunity cost of any one of dozens of better Ideas.

[asbo]

I'll be the first to admit: NumVotes is often not proportional to IdeaPowerOrUsefulness. Distributed Wires=356 versus Undo after Save=67 is a great example. I'm excited Distribute Wires is making it into the 2011 release, don't get me wrong, but it comes with the opportunity cost of any one of dozens of better Ideas.

I don't think the use of 'opportunity cost' is fair here - sure, one idea might get implemented and another might not, but I expect that it's rarely one idea OR another gets implemented. It may seem that way to us, but that's just perception (I hope).

Is there an idea you wanted pushed through that is comparable in the (perceived, at least) level of complexity of wire alignment? The block diagram cleanup aligns wires a-plenty, so there's probably not going to be much wheel-inventing to implement wire alignment tools.

[JackDunaway]

I don't think the use of 'opportunity cost' is fair here

I think it's fair. NI has limited resources, and assuming they're dutifully employed, the developers working on Distribute Wires are not working on something better.

Is there an idea you wanted pushed through that is comparable in the (perceived, at least) level of complexity of wire alignment?

Not specifically.

[Cat]

The block diagram cleanup aligns wires a-plenty, so there's probably not going to be much wheel-inventing to implement wire alignment tools.

As you say, my guess is there must be some aspect of "gathering the low-hanging fruit" going on.

Personally, if I look at my list of ongoing tasks and Project A will take only a couple days, and Project B will take months but is higher priority, odds are I'll find time to knock out Project A before Project B is finished.

Especially if the folks who are asking for Project A have said nice things about my code in the past.

[Aristos Queue]

I don't think the use of 'opportunity cost' is fair here - sure, one idea might get implemented and another might not, but I expect that it's rarely one idea OR another gets implemented. It may seem that way to us, but that's just perception (I hope).

It is definitely fair. It is always the case that one idea or another will get implemented, but not both. There are really good ideas on our brainstorm list that have been on the list since LV 1.0. Someday they may bubble to the top.

The idea exchange is not the sole arbiter of "what comes next". Various business interests can push a feature forward. An individual developer working in his/her domain can push a feature forward. What has changed in the last two years is that now the Idea Exchange can push a feature forward.

[Aristos Queue]

What is the difference between a "stability release" and a "patch"?

A reasonable question. First of all, you clipped the full phrase. I said "stability and performance release". The emphasis here is in going beyond basic functionality to fix issues that individually aren't important but collectively are.

A lot of the work is focusing on optimizing behind the scenes code. Good code development says "functionality first, optimize later." Decades of software research show that developers have a very poor sense for what will slow a product down, so trying to optimize code too soon generally just leads to code that is hard to maintain and doesn't actually hit the hotspot. It takes a lot of effort to get high performance code, and so LV R&D generally spends that effort on the execution engine, so that VIs run fast. We don't often spend time hammering the performance of edit-time features. Within an editor environment, lots of small slowdowns can be added and users won't really notice. Fixing them can be time consuming and doesn't actually improve the user experience. A good example is some new feature adding 100 ms to the launch time of the application. No one notices when the application launches slower by 100ms from one release to the next. But add 100ms every release for 10 releases, and suddenly a full second is definitely noticed. But when it comes time to fix that, each of those tedious 100ms fixes has to be tackled individually, diverting a lot of development effort from any other work.

Then there are the dark corners. For any set of features, each feature can be tested thoroughly in isolation. In that respect, it is functional. When you start testing the interactions between features, the possible interactions can exceed what developers can brainstorm. So two features used in conjunction may have unexpected behavior. I don't mean that it crashes, just that the results are counter intuitive. The vast majority of these are corner cases -- probably encountered by a small handful of customers at most. As such, they can go many releases before anyone reports them, and even when reported, they're not severe enough to get priority attention, especially if a workaround can be found. And they're not severe enough for the lone customer that reported it to stop using LV. It's an irritation, not a showstopper.

Any single dark corner may annoy a couple users. As the number of dark corners grows, each user has one corner that they are annoyed by. Eventually, that collective annoyance really can become a showstopper, even though no single dark corner in the collection is actually a serious problem. The best example I can point to is terminals on some nodes that are slightly not aligned with the general patterns of LV, so wiring to/from them always produces a 1 pixel kink wire. Have that on one node, not a critical issue. Have that on every node, critical issue. How many nodes does it take to make it a critical issue?

The difference between a patch and a stability and performance release is largely in the integration between features and how deep into the corners we sweep. A patch fixes very targeted bugs, bugs that crash, bugs that have been specifically noted by a large number of customers, or bugs affecting high profile features which have no workarounds available. This release is going after a lot of non-critical issues.

[ShaunR]

The difference between a patch and a stability and performance release is largely in the integration between features and how deep into the corners we sweep. A patch fixes very targeted bugs, bugs that crash, bugs that have been specifically noted by a large number of customers, or bugs affecting high profile features which have no workarounds available. This release is going after a lot of non-critical issues.

A fair comment. Although I do subscribe to the premiss that the corners are swept away on every release and a product up-issue is an extension of a rugged base. But then again, I'm more involved with mission critical software where even "minor" annoyances are unacceptable..

Lets hope the "Tabs Panel" resizing is fixed finally

Edited November 4, 2010 by ShaunR

[pallen]

I like being able to see the new ideas in development for the next version of LabVIEW.

Personally, I'm looking forward to the ability to undo after a save. Particularly if you've used an existing file as a template, made changes, and clicked "Save" instead of "Save As". There goes your original work. Forever. ( typically followed by a mournful, "Nooooooo!" And then a thudding sound as forehead meets desk. )

If only more programs had that ability.

[MikaelH]

There goes your original work. Forever. ( typically followed by a mournful, "Nooooooo!" And then a thudding sound as forehead meets desk. )

But then you realize that you just have to right click and select TortioseSVN->Revert to solve all your problems

[Black Pearl]

But then you realize that you just have to right click and select TortioseSVN->Revert to solve all your problems

Question: do you automatically check in vi's when they are saved?

Normally I work on a bunch of vis together and close (so save) them, but just check in the bunch together (including callers if recompiled) when a task is done.

As a side node:

I'm currently working on a large uml project (well, I'm working my way through the specs, so I guess I'm at 100+ classes) and Eclipse/Papyrus is crashing pretty often. :throwpc:Yesterday it managed to destroy the main model file. :frusty:Then I discovered that there was a build-in revision control, so I could revert to my last save (and due to the crashes I save often).

I'm not sure if there is a hook for saving/closing vis, but having them automagically commited to a SVN repository with a auto-message could be cool. Then of course not use SVN but Hq for multi-users so the check-in is only into your private repo and not breaking the build.

Felix.