Random Ramblings on LabVIEW Design

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

Re: The Difference Between P and D

swatts
Active Participant

Hello My Lovely LabVIEWers,

I had a bit of an epiphany when putting my slides together for my presentation in Madrid. It had to do with definition of things like OOD, LCOD and AOD with respect to OOP and LVOOP. It also began to make me think about the purpose of design.

 

I've given away that P=Programming and D=Design and I always call myself a designer (not a programmer).

 

But why is this distinction important? Well programming is for computers and design is for humans.

 

To clarify, you could program in a hideous fashion and as long as it is functionally correct the computer will not care one little bit.

 

Equals.png

 

The design parts is for when you want to help the human in the process. This help comes in many forms and what you want from your design is what should drive your design.

 

Here's some things to consider - SMORES, SMURF or SCRFFMRDM

 

At SSDC we've always held the Block Diagram as our favourite place to be and correspondingly our designs are Block Diagram-centric. We want to navigate our design via the block diagram and this means we tend to wrap our code in searchable/navigable structures.

 

The lesson here will be horrible for the people who want me to dictate a solution to their problem. This is because before you evaluate your design approach you'll need to ask the question.

 

If the design is for me, what do I want from it?

 

Lots of Love

Steve

Acronyms

OOD - Object Oriented Design

LCOD - LabVIEW Component Oriented Design

AOD - Actor Oriented Design

 

OOP - Object Oriented Programming

LVOOP - Work it out sucker!

 

 

 

 

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
FabiolaDelaCueva
Active Participant

Steve,

 

Excellent food for thought as always. 

 

Yesterday after the LabVIEW Architects Forum meeting we were talking about the part of our job that is not tangible. Allen Smith was talking about the Gang of Four approach in their book on Reference Designs. They wanted to find the equivalent of what architects use as reference designs. Architects have figured out general guidelines as to how people move in a space, then they go to the structural engineer to see if their idea can be built. Allen said that we are the software architects and the compiler is our structural engineer. We all agreed with that analogy.

 

Your post goes nicely along those lines. A programmer who follows no design and just codes and fixes their code as they go is the same as the mason that just lays bricks with no plans in place. 

A programmer who takes the time to model the solution, select an architecture, framework and/or design patterns, plans how they will test and validate that their code works, etc is no longer only a mason, they are also the architects, the designers that bring their big hopes and plans to the compiler and get a lovely piece of functioning art in return.

 

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?
swatts
Active Participant

Agree with all of that, although I would go a little further in that to some extent every "programmer" is a "designer". In fact the mason who just lays bricks is taking on the responsibility of the architect. The analogy works nicely here, by eschewing design you are making a design decision. And as we've discussed at length; there are implications.......

Steve


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


Random Ramblings Index
My Profile

FabiolaDelaCueva
Active Participant

Like we kept saying at the CLA Summit after your presentation:

 

"There is no bad code... just bad consequences" 🙂

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?
swatts
Active Participant

Discussing design in these terms are our small steps towards programming enlightenment!

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

Isn't there a Rush song about that.  I remember some lyrics something like: "If you choose not decide, you still have made a choice."


 

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

Making an old punk look up Rush lyrics is a crime in some countries, but I'm rather glad I did!

The song is freewill

You can choose a ready guide
In some celestial voice
If you choose not to decide
You still have made a choice
You can choose from phantom fears
And kindness that can kill
I will choose a path that’s clear
I will choose free will.

Steve


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


Random Ramblings Index
My Profile

Jim_Kring
Trusted Enthusiast