Is Agile right for Labview?

[MadMark666]

Hello All,

The question seems simple enough

Is Agile right for Labview?

But the answer seems more elusive because it only raises more questions.

1. Have any procedures or processes been produced to assist Labview developers in documenting their work?

2. Have any templates been produced to give them a starting point and ensure a consistent approach by all Labview Developers?

[swatts]

You have to bear in mind that Agile came about for industries that were just NOT delivering software at all, so the great step forward was "Let's deliver something to the customer and let them use it, or even get them involved in the process". For the vast majority of LabVIEW projects if you're not working in this fashion anyway then you are really not taking advantage of LabVIEW.

So my opinion is that LabVIEW precedes Agile and we should be creating our own methods and processes based on LabVIEWs unique way of working.

I've seen similar consultative money making ideas in other areas in industry and the best thing to do is to take the sensible stuff (of which there is a lot and you'll know it because it will make your life easier) and reject the dogmatic stuff. You'll then end up with a system that is useful to you.

[MadMark666]

True, but it would be useful if the creators of Labview had a set of processes available to end users to assist them in documenting it to a reasonable standard.

Documenting Labview seems a bit vague to say the least!

Some seem to regarding it as self documenting, 'well it's pictures isn't it!' being the normal line taken.

I could write lots of words to describe what my VI does or I could just show you the diagram.

It seems we need a new way of thinking to deal with Labview and graphical languages.

I can describe a how to paint a picture of a dog but until you see the picture of the dog I painted you'll still be unsure as to what it looks like or how good a painting it is.

The question is the why and how we tackle documenting code based around diagrams.

[swatts]

That's a different conversation than Agile.

My experience of documentation in any language is that it is the first thing to lie to you. The only truth is the code, so then it is upon us to create block diagrams that decribe how we have solved the problem clearly.

So labeling constants, using enums, labeling structures, colour coding icons, labeling array indexes, sensible naming of states and event, adding images to the block diagram are all techniques we use. But they are there to clarify the block diagram rather than document it.