Ramifications

[swatts]

Hello my engineering friends,

Had a lovely time promoting GDevCon and CTI at NI Connect and as I'm taking a breather from writing CTI drivers for the time being it appears I have some surplus energy to put into a blog article.

I had a lovely time in Fort Worth and really enjoyed hanging with everyone.

Before I start here's a picture of where the Austin Conference Center used to be (I think)

And Alan Smith showed me this at the end of the Fort Worth convention center. The water gardens is where Logans Run was filmed, I was in love with Jenny Agutter as a teenage boy.

Anyways to the article....

There's a lot of talk about which framework, workflow, methodology, technology is best and I think a lot of these conversations are missing the point. I also think that we as engineers could do a lot better when we consider all of these things... let me explain.

In the business world should be an emphasis on ROI (Return On Investment), in the engineering would we consider risk and mitigation. In the world of design I suggest we think about ramifications. 

Let's look at a fairly standard software dogma.

GLOBALS VARIABLES ARE BAD!!

Now explain why global variables are bad and "because someone I respect told me" does not count, we're engineers dammit!

I suggest you pause here and think on this, just for a couple of minutes, I'll wait........

......

......

OK, global variables can have the affect of making software difficult to comprehend if not managed. But it's even more nuanced than that, if you keep system state globally, it can really make systems hard to understand, if it's only displaying data it has no real affect on comprehension.

That tells us that the type of data held globally can be detrimental to comprehension or not...

Expanding the statement "Global variables are bad" to "The ramifications of using global variables are that using it for system state data can make your system more difficult to comprehend"  is much more nuanced and I would suggest accurate.

And sometimes using global variables is appropriate for your design, they're very efficient.

As an engineer/designer I have the option to sacrifice comprehension for efficiency.

I would like to see some more statements with "ramifications" in it. Maybe try and rewrite the next sentence see with "bad" or "best" in it.

As I think of examples I'll add them to comments, or you can too.

Lots of Love

Steve

[crossrulz]

I like this terminology: ramifications. It gives a slightly different angle to my approach to these types of discussions of asking the "Why?". I've seen too many people get dogmatic on a feature (ex Global Variables) purely because they were told so, but were never taught the reason behind the dogma. And then I see some "clever" engineers bend over backwards to accomplish the same thing, all of the ramifications included, but in a much less efficient manner.

[Intaris]

Well, it's essentially just "Context" (which is a clear concept in coding). There is a context associated with all such statements like "Globals variables are bad".

Funnily enough, declaring the statement of "Globals variables are bad" and REMOVING the context of the original statement, i.e. ignoring the ramifications, promotes the statement to a globally valid one and ends up being a violation of essentially the rule itself.

Happens all the time. It's just a symptom of the times we live in apparently. Too much information (social media, media in general, internet) leads to less effort being spent in categorising everything and we end up with bad abstractions of our own understanding. Which we then of course treat as valid categorisations and problems ensue. AI will massively accelerate this issue. Even higher volume of information, even less time to analyse.

I've started treating Software Engineering (At least in the area I'm active) more like a trade, not just a job. working from more basic principles, understanding the relations between different aspects and creating "bespoke" code. Just like being the carpenter I actually wanted to be when I was in school. BTW, I love this video for anyone who thinks "Trade" is somehow an insult. Here in Switzerland, Trades are highly valued. They are also inherently tied to a pride in the resulting work. Something that is rapidly disappearing in coding. In a way, it's a retention of culture.

[rolfk]

Of course are global variables bad! 😁

While I fully agree that context matters, and I sometimes use global variables too, it's also true that most beginners will start with them and get into a huge mess very quickly. So a bit of a commandment about this topic is not really bad. Once that tone is set, you can start to explain that it is not entirely black and white and there are valid reason to use them, but before you do you always should think at least twice if this is really such a reason. Just because it feels more easy is not a good reason, unless it is a quick and dirty trial and error test that you are sure to throw away right away after having tested something. And really throw away, not use with slight modifications anyway. 😀

[swatts]

Don't get too hung up on the Global Variables are bad argument, it's mainly just a generic example.

I could quite easily have gone with

OOP is the best way to program.

OOP is the worst way to program.

Comments are good

Comments are bad

Framework x is bad

Zero Coupling is good

AI is bad

each subject has a selection of ramifications to choose from

[swatts]

Just expanding the global conversation to bring some software engineering into the convo (just in case anyone is curious about the history of the topic)

Global data in your system can have bad side affects, but global variables are just 1 way of sharing data globally..

The correct software engineering term is common coupling and it's rated as a pretty bad programming decision.

Common Coupling: The modules have shared data such as global data structures. The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses, and reduced maintainability.

Databases, ini files, FGVs, shared variables, files are also ways of sharing data globally. 

If they involve an external shared resource (like a database) they can also be considered 

External Coupling: In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.

But sometimes you need to sacrifice maintainability for convenience, it's a perfectly adult engineering decision

[rolfk]

I fully agree here. The global variables was just a very easy and funny bandwagon to jump on. 😀

And while no coupling at all would be of course ideal in terms of maintenance as you can change anything independently without causing anything else to break, this is generally unachievable. Somewhere the components will have some coupling in some form as they usually need to work together. So trying to avoid any coupling is pretty much impossible in any practical system.

The question is seldom between no coupling at all or complete and tight coupling but rather a weak form of coupling that formalizes the interface but leaves the rest flexible and independent of each other. That's the theory at least. And then comes the practice, which usually ends up being a little less clear cut.

[swatts]

Here's a glimpse into my weird brain, I like a bit of coupling because I view it as a pathway through the code (i.e. it's the thread that helps link everything together)

[Bob_Schor]

     One of the more powerful metaphors in LabVIEW is the concept of the wire, which shows the flow of data (and what is Computer Programming but making use of and good sense out of data?). 

     In some sense, a Global Variable can be considered a "named piece of data", capable of being written or read, connected by "invisi-wires", so that writing to one Global instantly modifies them all.  This makes it something of a challenge to separate "cause" from "effect", particularly for large, complex programs.  I prefer Channel Wires.

Bob Schor

[joerg.hampel]

I would like to add that in my experience, it rarely makes sense to be completely correct from a theoretical, academic point of view. Applying the 80/20 rule, it's much more viable to get it right just enough to achieve your goal.

With this being said, I will happily agree that it's usually quite hard to pin that specific point down - when is something "just good enough"?