How open minded are you (in terms of software)?

[tomstickland]

This is interesting. I'm a mechanical engineer who's spent the best part of 10 years working on software. First with Matlab and Pascal, then Excel Visual Basic, then proper Visual Basic , then Labview and some C for DSP chips.

In that time I've made countless working applications that do what they're supposed to do, eradicated bugs and generally worked with other end users to make systems that are fast and easy to use. Most of the code has evolved or I've thought about how to do things on the drive to work or lying in bed at night. Some of it has been pretty involving, what with development work being quite unpredictable.

Over the last few years I've developed an automated production and test machine that involves motion control, hardware interafces, USB connections, serial ports, user interface, data processing, logic, a database, configuration options etc. It's pretty involving and there's still more ideas to implement.

I recently had some conversations with fully paid up "software engineers" who had been tasked with converting the system to Csharp and was quite amused by their narrow minded take on our situation. They seemed to have no interest in how one of our machines worked or a desire to take an overall look to see how complex it might be. They also used the following words which I have never used myself: core system architecture, class diagram, use case model.

Do you think that Labview users would tend to be more hardware/practical system solution orientated?

[Gary Rubin]

QUOTE(tomstickland @ Feb 14 2007, 07:12 PM)

Do you think that Labview users would tend to be more hardware/practical system solution orientated?

<soapbox>

I would guess that most Labview programmers view Labview, and the applications they generate with it, as tools or as means to an end. I would suspect that a "software engineer" is less likely to take that approach, and instead see the software itself as the ultimate goal.

Lest I get flamed by software engineers, I'd like to clarify that I don't think that ALL Software Engineers (capital-S, capital-E) would necessarily see the software itself as more important than the problem it's solving, just that someone with lots of formal software engineering training and education may be more likely to focus on the software, while as a group, we ad-hoc Labview programmers are more likely focus on the problem. After all, isn't that why we all became physicists, MEs, EEs, etc., rather than software engineers?

</soapbox>

[Chris Davis]

This could be an interesting discussion... I am a computer scientist by degree, not who you usually find using labview in the field. I also work for an engineering firm, that has me doing, computer software for engineers / scientists to use. I've worked with engineer groups who do nothing but code, and I work with several CS majors who do mostly DAQ coding. In general the engineering groups who program think of thier code as a means to an end, and they get caught up in feature creep issues, and lack the knowledge and desire to impliment ideas that are typically taught as part of a CS curriculum. I must admit that I don't impliment all the CS ideas they taught me in college, but over the last 7 years I have at least learned why they taught them.

[Aristos Queue]

I had an interesting argument with a customer at NI Week a few years back. I'm a computer scientist by degree and software engineer by trade. I was giving a presentation on good software engineering practices in LabVIEW. Early in the presentation we had discussed not having diagrams larger than a single screen and the judicious use of "Create SubVI from Selection". One customer in the crowd had mentioned his complete test harness for his hardware was in a single VI which took up nine screens (arranged 3x3, not nine in a line scrolling left to right) and he argued that this was better because he had everything right there in front of him with no jumping around to different files every time he needed to look at a different part of the structure. It was during this exchange that he casually mentioned having 90+ controls on the front panel that displayed the status of his test harness as it ran.

Later in the presentation, I was discussing software testing and how cool it was that every VI of LabVIEW was independently runnable. This would allow a programmer to run each function independently and test that each subVI worked correctly in isolation, a convenience not found in most programming languages. This made it easier to create a test harness to prove the correctness of the code. Well, that toasted this guy. "Are you telling me that I need a test harness for my test harness?!" I could only shrug and reply, "Well, if I had nine screens of VI code, and then I made a change somewhere in the middle of it, I'm not sure I'd trust myself to get it right without some way to test all the functionality." That got him to pause. See, for him, the code was, as you say, a means to an end. It was not itself an engineering project. The very concept of the test harness itself as something that could be engineered wrong -- where wrong in this case means "in such a way that errors are not detectable and modifications are not easily makable" -- hadn't really occurred to him.

You mentioned that the software engineers seemed uninterested in how the system worked or the overall complexity. I say "seemed" because if they really were uninterested then they are lousy software engineers and you should fire them. However, those unfamilar terms that you mentioned (core system architecture, class diagram, use case model) are the terms that a software engineer would use to understand a complex system. When you want to understand the structure of a building, you pull out the blueprints. When you want to understand software, you pull out the class diagram. When you want to know if a piece of hardware is ready to ship, you check off its test plan. When you want to do the same for software, you review the use case model. If you find a piece of software for which these items do not exist, then you have to generate them from the existing software before you can hope to make a significant refactoring of it and have any hope of maintaining the existing functionality. "Can we do this optimization? No, because it precludes this use case. Do we need this variable? Yes, because it provides this service. Can we simplify this data? Yes, by using this class hierarchy."

Ad hoc software works. One of the major goals of LabVIEW is to provide an environment where non-programmers can do incredible work without the CS/SoftEngr degree, where you can learn dos and donts in on-the-job training. But there comes a point -- generally when the software reaches a particular size and/or needs to be handed off to a new programmer or becomes a team project -- where ad hoc just isn't enough. In much the same way, a hobbyist can soder wires to breadboards and make circuits and even entire computers, but eventually an electrical engineer has to step in to clean up. Software engineering is very much in its infancy, but there are "best practices" that have developed over the decades to help bring order to the chaos and manage the complexity.

I have never met the software engineers that you're working with. But my guess is that they're no more or less "practical solution oriented" than hardware engineers. But they may well be judging "practical" on a whole different scale -- is it practical to have an ad hoc system that keeps growing over time and has no master architecture plan?

I wish you luck. Major overhauls of software are always painful --- huge amounts of work all so that the system can do exactly what it currently does. If a refactoring is done well, then there is no perceivable benefit to the end user at all (maybe a performance boost, but that's it). Refactoring is generally done so that after the refactoring is finished, the system is in a state where it can once again be managed, extended and improved. I'd suggest giving these guys the benefit of the doubt, and let them analyze the system and rephrase it in their own terms. You may discover that they grasp more than you think about the software and its relation to the real world task it is performing.

But, as I said, if you discover that they really are ignoring the software's end purpose then fire 'em. Or, if you can't do that, you might go online to your favorite bookseller and order a copy of Close to the Machine: Technophilia and Its Discontents by Ellen Ullman. It is the story of one programmer's education as she learns to understand the connection between the software she writes and the users it affects. I recommend it as reading to all programmers, and it might provide a subtle hint to your folks.

[robijn]

It's a very indicative story, AQ. I am always still very gladd that I can so clearly see (and test) what I am doing with LabVIEW.

QUOTE(Aristos Queue @ Feb 15 2007, 08:18 AM)

I have never met the software engineers that you're working with. But my guess is that they're no more or less "practical solution oriented" than hardware engineers. But they may well be judging "practical" on a whole different scale -- is it practical to have an ad hoc system that keeps growing over time and has no master architecture plan?

If you need to split up a big hardware project, you have to create clear boundaries. You make an "agreement" with the groups on where the boundaries between the parts should be and how they should be connected. That also goes for software. It often happens that these boundaries cost a lot of time, because the agreement was not understood in the same way on both sides. However, these problems are even greater if you need to cross the boundary between disciplines.

In my experience, when a system is multi-discipline, the time required to bridge these distances can (at least) be trippled. The more boundaries (software and electronics and mechanics and some physical process) the harder it becomes and the longer it takes. I think the reason for this is simply that the engineers in the separate fields have trouble understanding the problems of the other field, and interaction and therefor also progress goes at a very slow rate.

Joris

[dannyt]

QUOTE(tomstickland @ Feb 15 2007, 12:12 AM)

I recently had some conversations with fully paid up "software engineers" who had been tasked with converting the system to Csharp and was quite amused by their narrow minded take on our situation. They seemed to have no interest in how one of our machines worked or a desire to take an overall look to see how complex it might be.

I think this can cut both ways; I have, very occasionally, worked with electrical and mechanical engineer's, who could not give a damn about how the software works or any of its implemention issues. they refuse to consider any other group in there design. So I do think it is more down to the individuals in question, there are always people who will not look beyond what is their 'area'. (Generalization now) Having worked in both the telecoms and financial sectors, there is obviously a difference in the peoples experience, software engineers working in telecoms sector are, on the whole, daily dealing with projects that involve directly with hardware and issues that electrical and mechanical engineers would be more familiar with, in this area the software is often, only part of the product or is even only testing the product. In the financial sector the software tends to be the product and the focus is very different. There does have to be a paragin shift when you now from one sector to the other.

QUOTE(tomstickland @ Feb 15 2007, 12:12 AM)

They also used the following words which I have never used myself: core system architecture, class diagram, use case model.

This is a little hard to take as you have just been complaining (quite rightly) about the software engineer being narrow minded, surly you are doing the same with this comment. :headbang: You have hired a software engineer to utilise his expertise in software and then you do not want him to use best practise in his work, yes he should be interested in the 'whole system' and areas outside his software area, but that does NOT mean he should just ignore and throw any what training and experience he has. I do not mind when the RF engineers I work with go on for hours about 'coupling' and 'interference', or who mechanical engineers spend their lunch time rabbiting on about 'form fit' or their screw-fix catalogue .

QUOTE(tomstickland @ Feb 15 2007, 12:12 AM)

Do you think that Labview users would tend to be more hardware/practical system solution orientated?

I agree with all the was said by Aristos, in particular the point

QUOTE(Aristos Queue @ Feb 15 2007, 07:18 AM)

generally when the software reaches a particular size and/or needs to be handed off to a new programmer or becomes a team project -- where ad hoc just isn't enough.

This is where the software engineering terms and the focus on 'the software' start to become more and more important. I know software engineers who put their hand to mechanical design and have designs items that have ended up with customers, but I would not like to drive over a bridge build by a software engineer. As the size and scope of any project grows the attention to detail and best practice becomes more and more important.

The one area I find Labview to be really really poor, is the scaling up to large projects being worked on my multiple programmers, where software auditing \ tractability and reuse are key and I believe this is due to the history of Labview being a "non-programmers" programming language. This option may be due to my limited exposure to Labview plus I am still working with Labview 7.0. There does seem to have been quite a few improvements to this situation in the newer versions of Labview with the introduction of software projects, better software configuration control and other items, but they have been a VERY long time coming considering how long Labview has been around.

[xtal]

Well, this is certainly a good discussion that directly applies to my current situation. And it appears that I've inherited the worst of both worlds.

I agree completely with DannyT that LV doesn't scale well when you start adding developers and complexity to a project. My current workplace started out as one guy building the SW and HW. He chose LV and was very successful. Then he retired and was replaced with a couple of new people. They didn't get formal training on LV and when they modified the code or wrote their own, things got out of control. Fast forward five more years to when I join the team. Now each project gets an EE, ME, and Process Engineer. I am one of eight EEs on the team. The EEs are responsible for all the electrical components and all the software. The existing LV code is similar to the 9-screen program that Stephen describes - and add thousands of locals, globals, and ...now in LV 8.x, shared variables. The LV code isn't modular, isn't able to be easily modified by groups of people, and as a result, the entire group has decided to get rid of LV as a development environment and move everyone to C#. Most of the new hires already know C# and are successful in their projects quicker than they are able to write LV code.

I'd love to refactor all the existing LV code and show everyone that LV can be used as a proper SW Engineering tool. Unfortunately, all the existing code is FDA-regulated and revalidation is extremely slow and resource-intensive. I have no problems communicating with the other EEs when we talk about SW architecture and class organization and modular test and valiadation procedures, but we just have different preferred development environments.

My opinion is that it doesn't matter what your educational background is (EE, CS, whatever) or your current job title (SW Engineer, EE, ME, etc.), some people understand the modularization of SW and its integration with the HW and others are more short-sighted. Some people *get* LabVIEW and how to use it modularly and others don't. In the end, it's just about different tools and who is more efficient with what.

{back to reading my Learning C# book}

[Yair]

QUOTE(Aristos Queue @ Feb 15 2007, 09:18 AM)

I was discussing software testing and how cool it was that every VI of LabVIEW was independently runnable.

:worship: I didn't realize how much I take this for granted by now. It is only when explaining about LV to someone who doesn't know it or when being reminded like this that I remember how good this property is.

[Chris Davis]

QUOTE(Aristos Queue @ Feb 15 2007, 01:18 AM)

One customer in the crowd had mentioned his complete test harness for his hardware was in a single VI which took up nine screens (arranged 3x3, not nine in a line scrolling left to right) and he argued that this was better because he had everything right there in front of him with no jumping around to different files every time he needed to look at a different part of the structure. It was during this exchange that he casually mentioned having 90+ controls on the front panel that displayed the status of his test harness as it ran.

To a mechanical engineer this might be akin to machining a bridge out of a single piece of metal. Sure, it could be done, but what if one of the bridge supports breaks, you'd have to start all over.

[PaulG.]

QUOTE(Aristos Queue @ Feb 15 2007, 02:18 AM)

... Later in the presentation, I was discussing software testing and how cool it was that every VI of LabVIEW was independently runnable. This would allow a programmer to run each function independently and test that each sub VI worked correctly in isolation, a convenience not found in most programming languages ...

I agree. I think a lot of us are making this far more complicated than it needs to be. Caveat: thorough and accurate documentation of what the sw is supposed to DO is critical before any one of us sits down and codes one vi. An application may change dramatically, but LV is perfect for scalability, even when the scope of the project itself grows exponentially or if more engineers are taken out or brought in mid-stream. Yes, Q, the fact that every vi is independently runnable is one of LV's greatest strengths. I think that typedefs and nothing more than a "demo" or "simulation" boolean and fake inputs into our vi's are all the tools we need to self-validate and test our code - along with THOROUGH AND ACCURATE documentation. Did I mention we MUST have thorough and accurate documentation?

Quote me: "An accurate UML diagram is worth a dozen 'bugs' in Bugzilla".

[Mike Ashe]

QUOTE(dannyt @ Feb 15 2007, 04:32 AM)

The one area I find Labview to be really really poor, is the scaling up to large projects being worked on my multiple programmers, where software auditing \ tractability and reuse are key and I believe this is due to the history of Labview being a "non-programmers" programming language.

QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM)

I agree completely with DannyT that

LV

doesn't scale well when you start adding developers and complexity to a project.

With respect to your opinion, I have to disagree, or at least redirect the focus. LabVIEW actually scales pretty well, even with several programmers, separated by wide physical distance.

Cause & Effect. I agree with you on the observance of the Effect, but you have identified the wrong thing as the Cause, it is not LabVIEW. Lets look at an example of the pattern...

QUOTE

My current workplace started out as one guy building the SW and HW. He chose

LV

and was very successful. Then he retired and was replaced with a couple of new people. They didn't get formal training on

LV

and when they modified the code or wrote their own, things got out of control. .... The existing

LV

code is similar to the 9-screen program that Stephen describes - and add thousands of locals, globals, and ...now in

LV

8.x, shared variables. The

LV

code isn't modular, isn't able to be easily modified by groups of people, and as a result, the entire group has decided to get rid of

LV

as a development environment and move everyone to C#.

I love the fact that we now have Templates and Design Patterns. When you start a project you can now start a Project and pick Patterns for both the Project and each VI. Yes, I know you know this. You last quote above makes me think that we should have menu pick "Development Patterns", under two main categories: "Ad Hoc" and "Software Engineered". (with subtypes under each)

I cannot count the times that I have seen the "Ad Hoc:Creeping Feature" sub pattern for development (and yes I freely admit I've been quilty of it myself, lots of times). In fact, it happens so often that I'd say it is the norm, with LabVIEW project life-cycles, not that it should be. That is not the fault of LabVIEW.

QUOTE(Aristos Queue @ Feb 15 2007, 02:18 AM)

...Ad hoc software (

development

) works. ... (but) generally when the software reaches a particular size and/or needs to be handed off to a new programmer or becomes a team project -- where ad hoc (

development

) just isn't enough (anymore). ... Software engineering is very much in its infancy.

I agree with the "infancy" we don't remind ourselves of this often enough. To borrow from M. Scott Peck and para-rephrase (modular reuse and inheritance from an even older Zen teaching...?), "Software Development is difficult. Once we truly accept and understand this then Software Development is no longer difficult..." because we no longer expect and demand that it be easy.

Let me quote and paraphrase from Peck once more:

QUOTE

"This tendency to avoid problems and the emotional suffering inherent in them is the primary basis of all human mental illness. ...

Since most of us have this tendency to a greater or lesser degree, most of us are mentally ill to a greater or lesser degree, lacking complete mental health. Some of us will go to quite extraordinary lengths to avoid our problems and the suffering they cause, proceeding far afield from all that is clearly good and sensible in order to try to find an easy way out, building the most elaborate fantasies in which to live, sometimes to the toal exclusion of reality. In the succinctly elegant words of Carl Jung,

"Neurosis is always a substitute for legitimate suffering."

But the substitute itself ultimately becomes more painful than the legitimate suffering it was designed to avoid. The neurosis itself becomes the biggest problem.

This sounds so much like continuing to use Ad Hoc software development methods when they are no longer appropriate, to avoid the pain, boredom, tediousness, etc of the discipline of engineering the software and the software development process/pattern correctly for larger projects. It takes a lot of effort up front to develop a large project properly.

Now, although I said LabVIEW was not at fault, never the less it does contribute to holding onto Ad Hoc way to long. It is so easy to Ad Hoc small to medium size projects in LabVIEW that we tend to resent giving up the easy path when the time comes to shift into real SW engineering. With LabVIEW we get results almost instantly, immediate gratification. Thats great, in it's place. Just a little more from Peck

QUOTE

What are these tools, these techniques of suffering, these means of experiencing the pain of problems constructively that I call discipline? There are four: delaying of gratification, acceptance of responsibility,

dedication to truth

, and balancing...

The problem lies not in the complexity of the tools, but in the will to use them... "

I think the mapping from psychology to software here is pretty obvious.

QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM)

I'd love to refactor all the existing

LV

code and show everyone that

LV

can be used as a proper SW Engineering tool. ...

I have to express some grattitude here, because the project I am currently on is one where I am not only allowed to refactor some of their current software for reuse, but also the client's development process, while implementing a completely new "modular from the ground up" architecture for the new test system. They currently have a couple of dozen systems of the "9 panel, 3x3 or 9x1 diagram" variety of LabVIEW RealTime test stands, and they see the need and are willing to commit the resources to change their code and process. I haven't had a lot of clients over the years as willing and able. If only they could all be like this.

[Jim Kring]

QUOTE(dannyt @ Feb 15 2007, 01:32 AM)

The one area I find Labview to be really really poor, is the scaling up to large projects being worked on my multiple programmers, where software auditing tractability and reuse are key and I believe this is due to the history of Labview being a "non-programmers" programming language.

QUOTE(xtaldaz @ Feb 15 2007, 11:13 AM)

I agree completely with DannyT that

LV

doesn't scale well when you start adding developers and complexity to a project.

I'm with Mike on this one -- I respectfully (and strongly) disagree with this perspective. I feel that it's not fair to say that it is LabVIEW's fault that an application does not scale. LabVIEW applications can be made to scale just fine, but it does requires frameworks, software engineering (and team) know-how, and a lot of discipline to do so -- for example, you need some form of OOP design and framework, you need templates, automated builds, automated unit test execution, a well communicated software development process, collaboration tools, etc.

Sorry if I seem a little defensive, but I'm pretty fired up about this. I love LabVIEW (and need my applications to scale well) and thus, I've dedicated a significant fraction of my career working on tools that allow LabVIEW applications to scale and trying to educate myself and others on how to do better software engineering in LabVIEW.

I guess the point of my rant is that, in my opinion, we all need to focus on (and be vocal about) the real problem with the state of software engineering in LabVIEW -- that the state of software engineering tools for LabVIEW is pretty meager. And, NI isn't facilitating this, as much as they could, in my opinion. The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up scripting.

Cheers,

-Jim

[Val Brown]

QUOTE(Jim Kring @ Feb 18 2007, 02:11 PM)

I'm with Mike on this one -- I respectfully (and strongly) disagree with this perspective. I feel that it's not fair to say that it is LabVIEW's fault that an application does not scale. LabVIEW applications can be made to scale just fine, but it does requires frameworks, software engineering (and team) know-how, and a lot of discipline to do so -- for example, you need some form of OOP design and framework, you need templates, automated builds, automated unit test execution, a well communicated software development process, collaboration tools, etc.

Sorry if I seem a little defensive, but I'm pretty fired up about this. I love LabVIEW (and need my applications to scale well) and thus, I've dedicated a significant fraction of my career working on tools that allow LabVIEW applications to scale and trying to educate myself and others on how to do better software engineering in LabVIEW.

I guess the point of my rant is that, in my opinion, we all need to focus on (and be vocal about) the real problem with the state of software engineering in LabVIEW -- that the state of software engineering tools for LabVIEW is pretty meager. And, NI isn't facilitating this, as much as they could, in my opinion. The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up http://forums.lavag.org/LabVIEW-VI-Scripting-f29.html' target="_blank">scripting.

Cheers,

-Jim

I thnk I take somewhat of a "middle path" here.

LV scales well and allows for ad hoc programming, esp for fairly inexperienced system developers. Those are both strengths and both need to be kept in mind when pursuing these ideas.

Perhaps I'm a good example about this. I have a background in Unix, C, C++, BASIC, etc, etc and yet have done my development work in LV, beginning with LV5x. Why did I go with LV -- despite other members of the team virtually demanding C++? The primary reason was how well ad hoc development could be done, esp "promoting fast failures" through prototyping. Where have the problems occured? With integrating external DLLs and with serial interfacing. I've posted on the serial interfacing problem elsewhere and it's an interesting aspect of this entire situation. The long and short of it is that VISA has simply never worked well in my major project.

Now you would think that it would, but it doesn't and hasn't. And this despite the hard work of several LV consultants over the years and the work of NI to try to support the issues.

Development templates and scripting are wonderful but the real world interfacing also needs to be handled well and that's many times where the real implementation issues arise.

[Mike Ashe]

QUOTE(Jim Kring @ Feb 18 2007, 05:11 PM)

-- that the state of software engineering tools for LabVIEW is pretty meager. ...The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up http://forums.lavag.org/LabVIEW-VI-Scripting-f29.html' target="_blank">scripting.

I'd love to see both, although opening scripting is tops on my list. Yeah, lots of us are scripting away right now, but it feels like alchemy when it could be chemical engineering. I must slightly disagree with my friend in that having these two items he asks for, while really nice, won't solve the discipline problem directly, but would facilitate our (the community & NI together) making more tools to help automate and check the Design/Development Patterns in a LabVIEW Project.

Here's a semi-trivial example: A few years ago I was working on a project and had refactored a lot of the client's initial code to use error clusters and checking. I supplied several libraries of VIs and examples. Later there was a lot of support calls/emails about problems "with Mike's code", etc. I was at a loss to explain the problems until I arrived on site and started looking at how they were using my libraries. You guessed it, some error terminals were not wired up. Randomly it seemed. There was a lot of code. It took a while to track it all down and get it wired right.

During this I emailed one of the Elves at NI (Aristos, was that you?) who sent me a (diagram hidden) VI that I could use to scan through a bunch of VIs and check if my subVIs had the output error terminals wired on the calling diagrams. It was a wonderful little VI ... hidden. My real desire here, was to be able to inforce discipline in the development process, remotely, as there were thousands of miles between me and the client most of the time. Thanks again to the Unknown Elf (sorry, my memory is glitching) who helped.

Since then, I've learned how to do the same thing (and a lot more) myself using scripting. We need a large suite of Tools and Utilities that can scan a hierarchy, project, VI, etc for Design and Coding Standards. I really appreciate the effort NI is expending on the LV Project, etc, but the community could do a lot more. Opening up scripting would make it a lot easier.

Recently I was asked by several NI reps what NI could do to make enthusiasm go up and to help people adopt new features faster, the way us "guru oldtimers" did 10 years ago. It was pointed out to me that we were rabidly enthusiastic about LabVIEW then (and now, just with a little more elderly restraint ) and I was told that NI isn't seeing the same response. My answer is going to get truncated (because my son just said dinner is ready), but it seems to me that proportionately more effort has gone into making more and more items for the LabVIEW beginners, to get people to adopt LabVIEW. Well, I can't blame NI for wanting to make new sales, so do I. Nor am I denigrating some of the nifty features that do benefit more CS/Engineering and guru programmers. But I really would like to see a major version of LabVIEW come out where almost all of the efforts went into the types of things Jim was talking about above and other hard CS and CASE Tool type items like we've touched on in this thread.

It's been a couple of years since the "InYourDreams" thread on Info-LabVIEW, so I suppose it's past time for me to write up a new list to Santa's Elves.

The really nice thing is that this time I expect to get all of these things within a couple more years after asking. "InYourDreams" was semi-joking, but we now have almost everything on that list, except the single file executables again, and I can live without that.

Oops, second call for dinner, I'm in trouble...

[Jim Kring]

QUOTE(Mike Ashe @ Feb 18 2007, 04:03 PM)

I must slightly disagree with my friend in that having these two items he asks for, while really nice, won't solve the discipline problem directly, but would facilitate our (the community & NI together) making more tools to help automate and check the Design/Development Patterns in a LabVIEW Project.

Hi Mike,

We are in complete agreement. I didn't say that having better tools would be the panacea that turns every LabVIEW developer into a software engineer. (I see many "real" software developers using powerful tools every day, but nonetheless, doing poor software engineering. This is a problem that can't be solved. Some people will never be good software engineers -- if they are either too short-sighted or are unable/unwilling to think abstractly.) What I did say, is that the real problem is that we need better software engineering tools in LabVIEW and that this necessitates machine readable+writable source code (a precept of software engineering).

Cheers,

-Jim

[dannyt]

QUOTE(Jim Kring @ Feb 18 2007, 10:11 PM)

I'm with Mike on this one -- I respectfully (and strongly) disagree with this perspective. I feel that it's not fair to say that it is LabVIEW's fault that an application does not scale.

-Jim

Jim and Mike, I am more than happy to take on board your comment that Labview scales well, I did say in my post

QUOTE(dannyt @ Feb 15 2007, 09:32 AM)

This option may be due to my limited exposure to Labview plus I am still working with Labview 7.0.

I do think that thinks look so much better post version 8 of Labview with the introduction of Projects, better configuration control and much more. I am currently writing my own ClearCase handling VI's as version 7 has no concept of it.

The project I am working on has over 900 Vi's it works and does what it is supposed to do, we are therefore in a keep it going situation with minimum change. The problem is it gets harder and harder to keep it going and introduce newer features and small change can cause the re-linking of nearly all the VI's in the project. I would love the opportunity to break it apart into a more modular system, dynamically loading tests for example.

I do think that maybe Mike has hit the nail on the head with his comments on Ad Hoc software development, which in truth can happen in any Software Language.

My final comment is to Jim, if there is one application I have seen that leads me to believe that Labview projects can be scaled it must be the VI Package Manager, it gives me a feeling of well thought out, planned and executed piece of work, better I feel than some of the actual part of Labview itself. :worship: . I am sure that something like this can only be created by applying a structure software engineering approch.

cheers

danny

[Jim Kring]

QUOTE(dannyt @ Feb 19 2007, 02:36 AM)

Jim and Mike, I am more than happy to take on board your comment that Labview scales well, I did say in my post

Yes some things are getting better -- however, the reasons for me (personally) to not use the LabVIEW Project environment and native OOP outweigh the reasons to start using them. I'm eagerly waiting for someone to prove that it's time to make the switch. Certainly, if NI were to open up the project environment to outside developers (uh oh, Jim said "open" again) then I would be the first to start using it. And, me and my friends would probably create some very cool and useful tools that would give other LabVIEW users compelling reasons to start using the project environment.

QUOTE(dannyt @ Feb 19 2007, 02:36 AM)

I do think that thinks look so much better post version 8 of Labview with the introduction of Projects, better configuration control and much more.

I am currently writing my own ClearCase handling VI's as version 7 has no concept of it.

I used ClearCase, very breifly. I stopped using it when the system administrator told me that the only way to add files/folders recursively was through an obscure and very long command-line. Also, I did not have permission to delete or rename files. What a drag. Give me my SVN and let me get to work, already :-)

QUOTE(dannyt @ Feb 19 2007, 02:36 AM)

My final comment is to Jim, if there is one application I have seen that leads me to believe that Labview projects can be scaled it must be the VI Package Manager, it gives me a feeling of well thought out, planned and executed piece of work, better I feel than some of the actual part of Labview itself. :worship: . I am sure that something like this can only be created by applying a structure software engineering approch.

Thanks, that's a great compliment. Actually, we see VIPM in a similar way -- we want it to be proof that you can build sophisticated, cross-platform desktop applications in LabVIEW through software engineering. If we can do it, so can you If you're interested in some statistics, VIPM (main application) has about 1400 VIs (176 vi.lib, 263 openg.lib, and 80 jki.lib), the installer+uninstaller has about 150 VIs, and the automated build process is about 100 VIs. Actually VIPM has had its share of growing pains and refactoring. It wasn't perfectly thought-out from the start (few things are). But, our team is committed to improvement and finding ways to refactor and reuse code -- that makes a huge difference. Actually, one of the best parts about VIPM is that is enables software engineering through automated deployment and installation of LabVIEW tools and reuse libraries (yes, we're doing a lot of "eating our own dog food"). Adding configuration management capabilities is next on our list.

[xtal]

I guess I should have had a qualifier on my statement that LabVIEW doesn't scale well to larger projects and more developers. That qualifier is that LabVIEW code written by people who aren't educated in LV development, don't understand software engineering principles, and only write ad-hoc programs doesn't scale well. Nor is it easy to start using those principles on LV code written that way once you've seen the error or your ways or once you start thinking more abstractly. No, it's not the environment's fault; and I would argue that I love LabVIEW as much as both Mike and Jim. However, even with all the design patterns, SCC integration, and the project, it's not inherently obvious how those tools can be used in LV if you've only ever programmed in C# or nothing at all. And, quite frankly, I've found that there are some serious compatibility issues between VSS and the LV SCC features that never existed when I used Perforce. This makes the LV environment look kludgy and inconsistent for the C# developers.

And seriously, Jim and Mike, how can you say that scripting released as it is could really benefit all these people? I'm talking about the people who are the average software writers...not you who are not only LV enthusiasts, but are also the folks who "get it" when it comes to software engineering. I agree that if you are doing serious development work with LabVIEW and are writing utilities and applications that require flexibility and adaptability, you absolutely need many of the scripting features. However, I had full access to scripting for many years and there were just enough rusty nails or not-fully-functional or not-well-designed parts that I could't use a lot of it. I had to hack quite a bit of code to work around some of these limitations to the point where I probably shouldn't have even tried to use scripting. Scripting certainly didn't make me a better software engineer nor did it really help me understand LV any better, it just made it easier to crash in unexpected ways or otherwise get my LV into a very bad state. However, I'm not completely disagreeing with you. I think it's essential for NI to release LV scripting to power users such as yourselves (and me) in order to see what products/utilities can be made, what parts of scripting need enhancement, and how to properly package it when it is ready to be released to the general public.

So I think the best way to solve some of the general problems discussed is to just try and educate people as much as possible. And just as I said, Jim, your book is prominently displayed in my office and available to all these people as a reference. It's just that they are now so negative about LV that they won't listen to me and only make fun of all the LV items I have. Nor will they believe that proper initial SW design saves time and makes for more robust code in the long run. I just need to set the example and let my code speak for itself just as y'all have done for many years.

[Yair]

QUOTE(Mike Ashe @ Feb 19 2007, 02:03 AM)

We need a large suite of Tools and Utilities that can scan a hierarchy, project, VI, etc for Design and Coding Standards.

This does exist to an extent. The developer suite comes with the VI analyzer which uses scripting and can run a large number of tests on your code. I don't have any experience with it myself, but I think it might be possible to add your own tests to it.

[Mike Ashe]

QUOTE(xtaldaz @ Feb 19 2007, 01:18 PM)

I guess I should have had a qualifier ... that LabVIEW code written by people who aren't educated in LV development, don't understand software engineering principles, and only write ad-hoc programs doesn't scale well. Nor is it easy to start using those principles on LV code written that way once you've seen the error or your ways or once you start thinking more abstractly. No, it's not the environment's fault

Okay, we're getting closer to agreement. But you can substitute any language for LabVIEW in your quote and it would be as true. Especially, I think, about the part of trying to start doing things right on a really large project (code base) that is already screwed up. It is often much easier to "scrape the directory clean" and code up again from scratch, but that usually doesn't fly with budgets or management.

QUOTE

and I would argue that I love LabVIEW as much as both Mike and Jim.

Normally, I'd really have to disagree with that last statement, but anyone in a LabVIEW forum with an avatar like yours ...

QUOTE

And seriously, Jim and Mike, how can you say that scripting released as it is could really benefit all these people?

I don't think we said it would, at least not directly. But indirectly it would benefit everyone if scripting were (more) out in the open. Some of us would have an easier time making tools, those tools would benefit all. By the way, I'd like to make the points that: 1) a lot of us are making tools anyway, even though the cookie jar is on a higher shelf and the shelf has rusty nails. 2) my complaints and requests should not be taken as sour grapes. I'm very grateful that we have the scripting we do now. Or at least had. I really wish that at least NI would put us back into the state we were in for 7.1, :headbang: that if you could get to it it would work. Sigh... maybe during the next version

QUOTE

I had full access to scripting for many years and (it) certainly didn't make me a better software engineer nor did it really help me understand

LV

any better, it just made it easier to crash in unexpected ways or otherwise get my

LV

into a very bad state.

Hey, it just reminded me of the good ole days when both LabVIEW and Windows were in version 3.1. Wireworkers were still Real Men in those days, and wore out and replaced the Ctrl and S keys every other week or so. Come on now admit it, haven't you been missing your daily hourly dose of BSOD in the last few years?

No? Okay, well I don't think it would make most people, including me "a better software engineer", I just think it would make it easier for me to write some of those software engineering tools Jim & I are talking about.

To quote another favorite author:

"Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things." - R.A.H.

[Yair]

QUOTE(Mike Ashe @ Feb 20 2007, 04:12 AM)

Hey, it just reminded me of the good ole days when both LabVIEW and Windows were in version 3.1. Wireworkers were still Real Men in those days...

You should be careful when you say that to a woman (which you were). In some states, you could probably get sued.

QUOTE

"Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things."

- R.A.H.

Isn't Heinlein great? :laugh:

[Mike Ashe]

QUOTE(yen @ Feb 20 2007, 12:59 PM)

You should be careful when you say that to a woman (which you were). In some states, you could probably get sued.

Isn't Heinlein great? :laugh:

Yes, I know who Crystal is, we've met, and she has a good sense of humor (also a job situation that I'd kill for oops, guess the NI R&D job is in the past) and that's why I said the tongue-in-cheek. Also, when I spoke earlier about writing up another InYourDreams christmas list she was going to be one of the NI Elves I was am was going to send it to.

Yep, R.A.H. is cool. We don't see eye to eye on everything, but we do on enough that I've been a fan since I was 12. Nice thing with his works is that you can be a fan from 12 to 40-something and beyond. The Notebooks of LL are gems.

[xtal]

Yup, no worries. I do have a good sense of humor and since Mike and I know each other personally, I'd give him the benefit of the doubt even if he said something questionable

BTW, you should still envy my job because it's even better now.

[tomstickland]

I just found this discussion I'd started via Google!

My opinions haven't changed much. We can bandy words around, but nothing really compensates for imagination and ability by the developers.

Our system is very modular, because I tend to develop things in blocks. This is so changes can be made in the future with ease. I tend to break VI's up once they threaten to take up more than a screen, or maybe 1.5 screens at max.

I had an interesting conversation with another Labview user at work last week. He'd taken a look at a program developed by a "proper software engineer" type and found that he'd duplicated code in his program. We both agreed that as soon as we found ourselves duplicating then we'd make a subvi and use in it in both places. I actually advocate evolutionary design as a powerful process.

Anyway, I think all I'm saying is that talented developers can probably make good systems regardless of background/job title.

My overall opinion of Labview is that it's very good for rapid development and interfacing with hardware, but we've run into problems with handling large amounts of data. We've discovered some of the weaknesses of the platform. That said, I rate it over Visual Basic for the work I do by a large margin.