niACS wrote: But I've never known b) to be true on a project, and I'm generally opposed to extensive up-front requirements gathering anyway. I have also never been much for Big Design Up Front, which run contrary to assertion c. I'll agree that AF pushes you to do more design, but so far, I've been able to do just fine without extensive pre-design. |
Our opinions on the AF are tinted by what we're used to. "Traditional" Labview programming encourages tight coupling and monolithic applications that break every time you try to move stuff around. People coming to the AF from that world almost certainly find they need less pre-design than they previously did.
Earlier in my Labview career I worked in an environment where I had to be able to start with a simple two loop test app and continuously add whatever new features the engineers decided they needed, and I often had to do it in very short timeframes. When tens of millions of dollars are at risk, management doesn't accept "It can't be done in two days--I'll need 3 weeks to rearchitect the application" for an answer.
Over the years I developed techniques allow me change code quickly and easily with a minimum of fuss, and these techniques let me create robust and flexible applications with almost no up front design work. So when you say can do AF projects without extensive pre-design, I believe you. It still requires more pre-design work than I have to do now, so to me it is "a lot" of work, but to you it is not.
Michael Aivaliotis wrote: Does this mean that using AF makes it harder to work within an Agile development process? |
"Harder" is a relative word, so my question back to you is, "harder than what?" Harder than the techniques I use? Yes, in my opinion it is absolutely true it is harder to do an Agile development process using the AF than the way I develop. (Last year around the time of NI Week I started calling my methodology "Agile Actors" to reflect how light and easy they are to work with.) Harder than traditional Labview programming? Almost certainly not. Actor oriented programming and the AF offer a lot of advantages over traditional techniques. Harder than JKI SM based applications? Hmm... I dunno. I suspect the JKI SM is more similar to Agile Actors than it is to the AF, but I've never had the opportunity to see JKI code in the wild, so I can't say.
(Note: That doesn't mean I believe agile actors should be adopted by everyone. There are certain risks associated with Agile Actors I accept that may not be acceptable in other environments.)
AristosQueue wrote: No. It means that someone thinks that it does. |
While I agree with the sentiment--it is an opinion, not a fact--I will point out that it is opinion held by more than one person. I have talked to several LV architects who will not use the AF for various reasons. The common thread running through many of those reasons is this: using the AF slows us down and makes us less productive.
AristosQueue wrote: If I ever figure out how to unify them, yes. At the moment, and for the foreseeable future, it remains an area of research with no specific plans. |
I appreciate the update. Up until now I wasn't sure you even considered our reasons for not using the AF valid.
