Some Conclusions

[swatts]

Over the last 20 articles I've been discussing and thinking about design, methodologies etc. I think it's time to sit back in our smoking jackets, light up a cigar, pour a generous glass of brandy and have a bit of a recap. This is like a cheap episode of a TV series where they cobble together old clips.

My world view has been changed somewhat by the insightful input from you clever people. Obviously my world view is not going to be yours, but there is some useful stuff here I think.

So a few of the articles revolved around the concept of Cohesion and from this the discussion moved onto why our methodology doesn't give us the problems others have witnessed. Are all of our projects just inherently simpler or are we doing something others are not. Now this is something I have been really really thinking hard about and I have come to a conclusion. For us LCOD is a way of expressing our LabVIEW design with regards to Coupling, Cohesion and Information Hiding, because of this we are sensitive to communication paths, readability, abstraction. So if you just take the technique and design your components with no regard to how they talk to each other, the data they expose, the connectedness of their functionality you will end up with a poor LCOD design.

The exact same thing applies to LVOOP, you could conceivably make one big class, that contains all the data used by the program and has 150 methods that describe all the functionality of the program. This obviously would be a bad design but does it make LVOOP a bad methodology?.

The same will apply to actor framework I bet.

I think this demonstrates an over-riding interest in the community regarding techniques over actual design. This can be seen from the lack of comment and lower audiences for the more design oriented articles. (Cohesion for VIs and your State Machine, Databases with Jonny and Stevey, CODE Smell: if not EASY and not SIMPLE or not UNDERSTANDABLE=COMPLEX LOGIC!). Now personally I think the State Machine stuff is really something worth thinking about.

The other thing I have learnt is that use cases are very important when talking about methodology. I think some of the initial friction was due to the difference of the techniques for designing tools, compared to complete systems. Pretty much all of my discussions are regarding complete systems. For tools think DAQmx Tool Palette. From our perspective these lack cohesion, and this is absolutely correct. It is our job to take this non-cohesive, scaleable bunch of VIs and make them into cohesive modules (components, classes, actors)

If you're a complete stats addict (as I appear to be) you'd monitor the various numbers on the blog pages. As I understand it the #views increments every time someone lands on that exact page. To my amusement the page that gets consistent hits every week as if it has come from a search engine is the Universal Test Framework, an article making fun of the concept of a system that can test anything is now number 2 in the google searches for such a thing.

Oh if you want to hear the noises that come out of my face I invite you to jump to VI Shots (I never knew I sounded so cockney)

Anyways I hope you've enjoyed the last 20 articles.

Lots of Love

Steve