Random Ramblings on LabVIEW Design

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

Re: Creativity Needs Discipline

Active Participant

Hello Lovelies,

 

"Character cannot be developed in ease and quiet. Only through experience of trial and suffering can the soul be strengthened, ambition inspired, and success achieved." Helen Keller

I strongly suggest popping over to wikipedia and checking this lady out

https://en.wikipedia.org/wiki/Helen_Keller

 

Over the years my experience in software design have taught me valuable lessons. To emphasise the point I'll draw on other creative occupations.

 

Lesson #1 Graft

 

I may have mentioned before that I collect comic art and comic artists are very similar to LabVIEW programmers.

 

12983931_1186077544766171_6983570471184095147_o.jpgBad picture of 1 of my favourite pages

The difference between a good artist and a poor artist is not just down to talent.

 

Check out this guide to life drawing - Bridgman Complete Guide to Life Drawing. You can see here that there is a considerable application of effort to the seemingly throwaway world of comic art. Comic artists become good through drawing a lot.

 

OK so that's hard graft covered, but that's not the full story.

 

Lesson #2 Discipline

 

The guide is also a demonstration of learning rules and applying them, doing this requires discipline.

 

The common push-back I get from programmers about using methodologies and rules to help in our designs is that we're removing creativity from the process. Well, guess what, I disagree.

 

I think creativity needs discipline or conversely lack of discipline hampers creativity.

 

Creativity should be applied to solving customer requirements, it shouldn't be applied to find new and interesting ways to solve already solved problems.

 

Using artists as our study, we can see that they practice drawing hands for hours and hours, bodies and faces adhere to strict ratios and shapes. 

 

they use the rules of perspective to frame the picture. They use photo referencing, colour referencing, quick thumbnail sketches even copying other artists that they like. This is counter-intuitive to the outsiders view of a purely creative occupation.

 

This is very analogous to applying software design rules like coupling, cohesion, encapsulation and information hiding. To creating diagrams for our state machines, databases or object hierarchies. Using rough prototypes as the quick sketches that describe the design with little investment of ego as well as $$$$.

 

So why in a so-called engineering field like software design do we not work with more discipline? I wonder if it's just because we can and we can because our customers seem to have a low expectation of us.....

 

I like the analogies here.

 

But for now it's back to work for me.

Lots of Love

Steve

 

 

 

 

Comments
Active Participant

I think there is a lot of truth to this.

 

I have been going through the process of systematising a lot of my business and my work where it makes sense. "Processes, pah! What about freedom!" is the cry you hear from some people. But these processes make the everyday simple and means I have more energy to be creative where it is required.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are atdevs.wiresmithtech.com
Active Participant

You get extra Kudos for quick read and response James <5 minutes!

 

I think it's a battle we all fight within ourselves too. 

 

My experience with rescuing software from very "creative" programmers is that they are generally very good at creating a mess!

Member

I wish you had an example of "creative programmers . . . creating a mess!"  I feel like all of labview is a mess.  I just try as hard as I can to be neat.  But just a little bit lazy or if I didn't make my outer structure large enough.  All of a sudden I start to squeeze things in.  And I tell myself, it is just one object.  And I let it slide.  Then 1 becomes 2 or 3.  Then I have to decide if I should make a new sub vi.  Or should I stretch my structures a bit.  Or let the mess sit there, haunting me.  Worrying what would another programmer think of me, and why I produce lazy code.

 

So what is a mess; compared to labview being labview ( a graphical program)?

Member

I think people are at their most creative when there are rules or boundaries.  If there are no rules or boundaries then anything goes.  But when you have to stay between the lines sometimes it forces you to come up with a more creative solution.

Sam Taggart
CLA, CPI, LabVIEW Champion
automatedenver.com
Active Participant

Hi Richard,

Welcome to the dark side.

I certainly wouldn't call my code a mess. I have a scruffy exterior but I think I have a tidy mind!

 

In any programming language a lack of planning, research and adherence to rules will result in messy code. One of the joys of graphical programming is that this untidiness can be clearly seen, believe me it's there in other languages!.

 

Here's a non-comprehensive list of the things we do to stop our code becoming messy.

 

Apply and understand coupling, cohesion, encapsulation and information hiding

Colour code VIs

In code commenting - labels, enums, labelled constants, polymorphic selectors.

Reduce/remove complex logic

Abstraction

Project templates that enforce the above

code reviews

design reviews

project post-mortems

Simple is best 99% of the time

 

Some of these are hard work, some are easy.

If you are new to the blog I recommend you read some of the articles in the Design section below.

https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Index-to-Articles/ba-p/3486105

 

Hopefully it tackles some of your points.

 

On the point of worrying about what people think about your code

1) I would first of all make a list of people whose opinions you care about (hint: my list is very very small).

2) That worry is there to motivate you to work on your programming skills, it's a good thing if used for positive. If it demotivates you and shrinks your ego take a breather and think about the practical aspects of your code.

 

Primarily good code works at the job it's supposed to do, design etc are there to make it easier to work on, share, extend, maintain and all the other things people want from code. But most projects don't need all of them and the fact that it works is a great first tick in the box.

 

Keep on keeping on

Steve

 

 

 

 

 

 

 

 

 

Knight of NI

In regards to the "Processes, pah! What about freedom!": pretty much every time I try to go around the system it bites me in the arse.  Processes are there for a reason, usually for good reasons.  Most importantly, they keep you on the task at hand.  I hate doing documentation (I have been doing almost nothing but procedures for the last couple of months), but it is vitally important for a successful program.  If we could go and do whatever we want, the needs of the customer would not be met and then we would be quickly out of a job.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines