LabVIEW Champions Reading Resource Center

cancel
Showing results for 
Search instead for 
Did you mean: 

Is Agile right for Labview?

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?

0 Kudos
Message 1 of 4
(4,984 Views)

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.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Message 2 of 4
(4,379 Views)

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.

0 Kudos
Message 3 of 4
(4,379 Views)

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.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

0 Kudos
Message 4 of 4
(4,379 Views)