Poll: Should the CLA Exam require applied knowledge of OOP?

[Mike Le]

Hi all,

I was having this discussion with some coworkers. We were wondering if a CLA should imply that you are familiar and comfortable with LVOOP. If so, then it would seem the format or rubric of the CLA exam should change.

Current CLAs would be grandfathered in, so this is a question for how future CLAs should be vetted.

[CaseyM]

I think yes. If you're architecting code and not aware of OOP principles and LVOOP itself, you're probably hindering your efforts. This is an advanced certification so I think it's fair to require people to know about these ideas. I'd certainly expect someone with a CLA to at least be familiar with LVOOP if I were hiring.

The key difference between this and other "advanced" topics is that I see OOP as pretty fundamental to good architectures. Obviously there are places where LVOOP might not be appropriate or even possible, but for a general CLA certification, I think this makes sense. LVOOP is ~15 years old by now so it's not like people haven't had time to learn it like was the case when the CLA certification and LVOOP were both fairly new.

[Neil Pate]

Interesting question. I would say yes due to the fundamental nature of OOP but what worries me is the natural next step then is to say that The Actor Framework is also something a CLA should have applied knowledge of, and that would not be sensible.

[LogMAN]

I believe it should.

OOP (and interfaces in the near future) are architecturally relevant and at the core of frameworks and libraries that drive so many applications. A CLA should be able to assess if a particular framework is a good choice architecturally, or not. A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it.

It probably makes sense to focus on fundamental concepts in the exam, because frameworks and libraries eventually get outdated and replaced by new ones.

[ShaunR]

47 minutes ago, LogMAN said:

A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it.

I've never read such a load of clap-trap on this forum.

[LogMAN]

5 minutes ago, ShaunR said:

I've never read such a load of clap-trap on this forum.

Did you only come here to mock me?

If you disagree with something I said, please feel free to express your point of view and perhaps we can find common ground.

[The Q]

Yes, definitely for CLAs.  OOP is fundamental in almost every other high-order programming language, why should G be any different.  In fact, I believe, NI should teach OOP a lot earlier in the Core classes.  If for nothing else, to teach encapsulation.  Inheritance and overrides can come later but CLAs should be familiar with all those concepts.

See "Encapsulation in King! by Daniel Harryman from GDevCon#1" for a good example of why and how to teach this.

 

[ShaunR]

2 hours ago, LogMAN said:

Did you only come here to mock me?

Actually. Yes. Elitist zealotry deserves mocking.

2 hours ago, The Q said:

Yes, definitely for CLAs.  OOP is fundamental in almost every other high-order programming language, why should G be any different. 

Because it is not what is being tested in a CLA exam: 

Quote

A CLA demonstrates mastery in analyzing and interpreting customer requirements for the development of scalable application architectures in LabVIEW, organized in a modular project hierarchy with the intent to be fully developed later by a multi-developer team.

How a CLA achieves that is not dependent on OOP.

Edited December 19, 2020 by ShaunR

[The Q]

3 hours ago, ShaunR said:

Because it is not what is being tested in a CLA exam: 

How a CLA achieves that is not dependent on OOP.

Fair point. I can see your point of view that it is a tool to accomplish the objective and not necessarily the objective. 
 

3 hours ago, ShaunR said:

Actually. Yes. Elitist zealotry deserves mocking.

I don’t see it as elitist and there is no reason to be rude. 

I’m an engineer not a computer scientist by degree. So I didn’t learn OOP initially. However, I think it is an important skill to learn. 

Edited December 19, 2020 by The Q

[crossrulz]

Coming from my personal experience, I still lean towards no.  I had a discussion with Nancy Hanson about this and we came the the conclusion that the CLA was not a destination, but the opening of doors to learn (yes, this was alluding to the CLA Summits).  Personally, I had 0 experience using OOP when I got my CLA.  But after my second CLA Summit, I found an application that deserved a very basic OOP architecture.  The CLA Summit opened that door for me.  Now I would say ~50% of what I do is OOP.  There is still A LOT you can do effectively without OOP.  And keep in mind that part of a CLA is to make architectures that your less experienced developers can use and understand.  If they can't use OOP, then your OOP architectures will not be effective.

So should it be REQUIRED?  No.  Highly recommended?  Absolutely.

[LogMAN]

11 hours ago, ShaunR said:

Actually. Yes. Elitist zealotry deserves mocking.

Actually had to google that. If I understand it correctly, you are saying that my sentence is phrased in a way that is offensive to you (and others perhaps). That was not my intention. Let me try to explain myself and hopefully clear up what I presume is a misunderstanding.

15 hours ago, LogMAN said:

A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it.

By "A CLA who isn't familiar with fundamental OOP concepts..." I mean somebody who has no prior knowledge about OOP whatsoever. They don't know what a class is and how inheritance or encapsulation works. It is my opinion that this makes them incapable of choosing between different OOP frameworks and libraries themselves (of course they could ask somebody they trust).

For the second part "and in worse case puts the entire project at risk by making random decisions" imagine somebody without any prior knowledge about OOP being brought into a project that is heavily based on OOP (i.e. using Actor Framework). They are brought in by management to evaluate the situation and get the product ready for market. Of course management will listen to the CLA as an expert (as they should).

If the CLA ignores the fact that they don't know anything about OOP (worse case scenario), the best they can do is decide based on their instinct, feedback from other developers, or simply by tossing a coin and hope for the best. There is a great chance that this will put the project at risk because everyone listens to that expert. I can't be the only one who went down this rabbit hole.

The last part "or avoiding OOP because they don't see the value in it" is about changing architecture late in a project because of a personal vendetta against OOP. Let's take the example from before. The CLA might decide that Actor Framework is not a good solution simply because they don't like OOP stuff. So they tell management to toss everything away because it's "no good" and start from scratch using their own approach.

Unless the architect has really good arguments, decisions like that are toxic to any project. I have actually experienced a situation that went in the opposite direction (replacing everything with objects because OOP is THE way to go). We eventually reverted to what we had before thanks to the power of Git. (that was probably the most expensive revert we did - so far).

Just to clear up one additional point because I believe that it didn't come across in my original post. I believe that there is value in OOP but I don't think it is the only answer to everything. On the contrary. Frameworks like DQMH completely eradicate the need for frameworks like the Actor Framework. Depending on your needs and what you feel more comfortable with, either one is a great choice. I simply expect a CLA to have basic knowledge about OOP, even if they decide against it.

[crossrulz]

8 hours ago, LogMAN said:

For the second part "and in worse case puts the entire project at risk by making random decisions" imagine somebody without any prior knowledge about OOP being brought into a project that is heavily based on OOP (i.e. using Actor Framework). They are brought in by management to evaluate the situation and get the product ready for market. Of course management will listen to the CLA as an expert (as they should).

Now imagine a "Senior Engineer" being brought in on a project and being told to redo everything because you used an Event Structure.  No, I am not exaggerating.  He had issues with the Event Structure in LabVIEW 6 and swore them off forever.  Good thing I didn't listen to him, managed to get him to leave me alone, and the project was successful.  My point here is that titles should be taken with a grain of salt.

[ShaunR]

51 minutes ago, crossrulz said:

Now imagine a "Senior Engineer" being brought in on a project and being told to redo everything because you used an Event Structure.  No, I am not exaggerating.  He had issues with the Event Structure in LabVIEW 6 and swore them off forever.  Good thing I didn't listen to him, managed to get him to leave me alone, and the project was successful.  My point here is that titles should be taken with a grain of salt.

I was once told by an engineer (I think he might have been a Senior Engineer) that it was ok and even desirable to allow broken trunks in the Source Control. He read it in a book, apparently. Glad he wasn't on my project.

[drjdpowell]

I note that even though I created a framework, Messenger Library, I did not re-architect any existing project using my framework, but instead just used it to add new features to those projects.  Then I used Messenger Library for all new projects, armed with actual experience.  Trying to rework the entire architecture of a large project sounds very expensive and risky.  

[Rolf Kalbermatter]

3 hours ago, drjdpowell said:

Trying to rework the entire architecture of a large project sounds very expensive and risky.  

Point in case: LabVIEW NXG!

Edited December 21, 2020 by Rolf Kalbermatter

[LogMAN]

On 12/20/2020 at 5:31 PM, crossrulz said:

Now imagine a "Senior Engineer" being brought in on a project and being told to redo everything because you used an Event Structure.  No, I am not exaggerating.  He had issues with the Event Structure in LabVIEW 6 and swore them off forever.  Good thing I didn't listen to him, managed to get him to leave me alone, and the project was successful.

Glad to hear it worked out well for you. I wish I had this confidence 10 years ago...

On 12/20/2020 at 5:31 PM, crossrulz said:

My point here is that titles should be taken with a grain of salt.

I agree. Unfortunately the decision is not always up to us, especially for young teams without expert recognized by higher-ups. In our case it went something like this: 

NI is also not very helpful in dampening expectations:

Quote

The Certified LabVIEW Architect (CLA) is the final step in the three-part LabVIEW certification process. The exam verifies the user’s ability to build a sensible VI hierarchy and project plan for delivering an application that fulfills a set of high-level requirements. Certified Architects provide technical leadership, helping ensure the developers on their team follow best practices and become more competent and efficient developers.

-- Certified LabVIEW Architect (CLA) - National Instruments (ni.com)

The rest is history.

To be fair, our case was a single incident. The general experience with contractors has been very positive and insightful. Still, I would probably raise an eyebrow if a CLA told me that they don't know how to work with classes. Just seems weird considering that it is the final stage in the certification process.

6 hours ago, drjdpowell said:

Trying to rework the entire architecture of a large project sounds very expensive and risky.

Funny how you spell "is" 😄

[D_Hooks]

I guess there could be some discussion around whether or not the CLA exam is the best place to test LVOOP knowledge, but I think it is definitely a topic that a CLA should be familiar with.  LVOOP obviously isn't the right answer to every problem, but it is definitely an important G language feature.  Being completely unfamiliar with it would really limit a CLAs ability to make informed architecture decisions.

 

[Tim_S]

I have to say no for applied knowledge. I think should be aware of when it is advantageous and inappropriate to use OOP, but that falls short of applied knowledge.