Jump to content

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


Mike Le

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

32 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment
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.

Link to comment

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.

 

  • Like 1
Link to comment
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 by ShaunR
Link to comment
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 by The Q
  • Like 1
Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment

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.  

  • Like 1
Link to comment
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: 

4r74i2.jpg.dde4f950ebe7b7f60b0e49b412276812.jpg

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" 😄

  • Haha 1
Link to comment

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.

 

Link to comment
  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.