Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Centrist Approach to Process and Design

swatts
Active Participant

Hello Weary Travellers (for those who have travelled)

Well that was an enjoyable NIWeek! I'll do a diary of my travels around the USA next blog, needless to say I went to a lot of odd places and had a great deal of fun.

 

Here's a piccie of some wild flowers that I saw with the lovely people Fabiola, Brian and Matthias.

Wildflower CenterWildflower Center

One question I get asked often is about whether I love xxx or hate xxx and if I were to make an observation it is that software design seems to be an all or nothing occupation. It seems to be something peculiar to software engineers. I've never heard builders being pro or anti-screwdriver, they are just tools to do a job.

I also think that our software community doesn't evaluate shiny new things as befits scientists and engineers. 

 

As I hopefully ascend the ramp to programming enlightenment I would like to propose a centrist position. I think that the best way to program is to use a particular technique where it is most appropriate. Here's some examples where I think the moderate approach leads to better outcome...

 

First let's look at Agile.

There are times in a project life-cycle where Agile is appropriate, but I will contend that there are also times when it isn't. For us the start is Agile, then the project goes into a more disciplined life-cycle and then from Beta we're back being Agile again.

 

Now let's look at OOP.

I have reached a bit of an epiphany with regards what works well and what doesn't. It's a bit earth-shattering, but I've not seen it put this way before.

 

OOP works well when it is a tangible object (hardware, report etc), I think when you start getting contrived objects like moderators, managers, factories, facilitators etc there is a clearer way to program. Here the mixture of procedural and objects comes together nicely for us.

 

Similarly Actor stuff works best when there is a definite need for an asynchronous process (we call them services).

 

Globals?

Globals are neither evil or brilliant. They are just a technique for passing global data and sometimes this is cleaner than all the knots people tie themselves into with pseudo-globals (DVRs, FGVs, Shared Variables, Named Qs etc <-- these are all global data!). The thing with global is write once and read many times. If you're writing many times you need to think of encapsulation.

 

Add to this the extra variable of use-case and you can see that being a purist may be an expensive past-time. Use the tools appropriate to your use-case and life will be less stressful for everyone.

Maybe the centre-ground is the path to get our most efficient designs.

Lots of Love

 

Steve


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


Random Ramblings Index
My Profile

Comments
cbutcher
Trusted Enthusiast

Nice analogy with the screwdriver. I think it's probably nice to have a wider toolbox but I guess it takes time to acquire all the tools.

 

Reading the forums is a nice way to try and see things you don't usually do. NI Week is great but of course difficult (unwise?) to show detailed coding...


GCentral
swatts
Active Participant

There's no shortcut IMO, just time and experience. But I would rather be in a job where I'm still learning after 30+ years than be a master of all I survey.

The real difficulty with all of this is that it's only meaningful for large complex projects and it's hard to gain entry level education in large complex projects. As there's little CS on large complex projects we're reliant on my kind of "Sample Of One" brain dumps.

 

I'm biased against purity so my thoughts are likely biased.

Steve


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


Random Ramblings Index
My Profile

Taggart
Active Participant

I totally agree with the sentiment, it's all about the best tool for the job. 

 

Although sometimes I find the best tool for the job is the one you know best.

 

One small disagreement.  DVRs are not global unless you share them globally.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
FabiolaDelaCueva
Active Participant

Hi Steve,

It was lovely to see you again and that visit to the Lady Bird Johnson Wildflower Center was a nice way to recover from NI Week.


@swatts wrote:

Now let's look at OOP.

I have reached a bit of an epiphany with regards what works well and what doesn't. It's a bit earth-shattering, but I've not seen it put this way before.

 

OOP works well when it is a tangible object (hardware, report etc)...

 


I am pretty sure you and I have had this conversation before and it might have even been included in a chapter of a certain book that you reviewed that will be published later this year (wink wink 😉

 

I completely agree with you, I find that that OOP works best for things that we can touch. Trying to convert every case structure into a dynamic dispatch and every single cluster into an object might lead to code that has very well defined little pieces that work well on their own but that nobody knows how to put them together. As always it is all about the balance.

 

I can think of a piece of furniture from IKEA, they give you already parts of the furniture assembled and it seems possible (although I would advise not to try it) to assemble the furniture without following the instructions. You can clearly see these are the handles, these are the feet, etc. It is by no means a bunch of pieces of wood, screws, and tools that would be impossible to assemble without any instructions.

 

Thanks for reminding us to look at why we use some tools in our toolbox and keep in mind that at the end of the day, we are trying to get our job done and help our customers solve problems. We are not on the pursuit of the purest and most shiny code that might not solve anybody's problem!

 

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
drjdpowell
Trusted Enthusiast

As a counterpoint to "a wider toolbox", I note that screwdrivers have no learning curve.  If a builder had spent 6 months in apprenticeship and had 5 years of experience building walls with bricks, then when presented with a different way of building walls (one that requires a 6-month apprenticeship and experience to do well) the are likely to say "I'll just stick with bricks, thanks".

swatts
Active Participant

@Sam - A global can be restricted if it is privately scoped in a library too. My point is that we bend over backwards not to use a global, but quote often the solution is a global by any other name. If the data is globally available for reading and writing it is global. 

@Fab - The wildflower centre is one of the nicest days I've had in Austin, everyone should avoid going there, keep it nice and empty for me to enjoy!

@James - that's a good point and like Sam says one of the considerations is the comfort of familiarity.

Steve


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


Random Ramblings Index
My Profile