Company Views on LabVIEW

[GregFreeman]

Because LabVIEW is not something necessarily tought in school, I have noticed that just because you are a "super senior amazing best in the world" software engineer doesn't necessarily mean you know what you are doing with LabVIEW. I am 23, just out of college, and am no way a LabVIEW expert, but I can at least open a VI and know that a main VI taking up 2 1/2 17 inch monitors means someting could probably be done differently. I see this problem at work, on top of tons of stacked sequences feeding data into different frames, frames including stuff that could be put into a subVI and take up 1/10 of the space they currently do, etc. I think that LabVIEW at my company is viewed more as a "get it done, it works, does our testing, lets move on" type  application. I was wondering if anyone else has had this "problem" and how they went about influencing change? Especially being a lowly first level software engineer,  I don't want to overstep my boundary telling someone higher than me stuff is done poorly (maybe even stuff they did), but I am not a fan of looking at a block diagram and having to scroll across multiple screens to try to figure out whats going on.

Basically, stuff can just be a mess and I'm sure other people have run into this problem, and I'm wondering how they dealt with this.

Yes this post isn't about coding specifically, but I still think its an interesting question.

Message Edited by for(imstuck) on 10-17-2009 09:14 AM

[Jason_P]

Two thoughts come to mind -

1) You can't make people change their minds.  Just show them the right way to do things, and if the benefits are there they'll change on their own.  When your code runs quickly, doesn't hog memory, and can be changed at the drop of a hat, they'll start using your techniques.

2) They may be right.  In my group, all the developers write solid code.  The problem is that one or two are more concerned with the code than the product.  Perfect code that is 6 months late isn't any more useful than ugly code that runs when you need it...  You have to strike a balance, and understand that the balance will sometimes shift depending on the situation.

Just my 2 cents.

Jason

[smercurio_fc]

What you are seeing is not specific to LabVIEW. It happens with all programming environments as well as hardware because it's a people issue, not a programming language issue. Jason is right - you have to strike a balance. The real world is way different than the college world. Sounds like a platitude, but it's the harsh reality. In the real world people don't want to be told that what they're doing is wrong or inefficient as people tend to be defensive about these things and they may start treating you as the kid who thinks he knows everything. The key is to start out small and show how things can be improved little by little. This has a better chance of success since it's easier for someone to accept a small change than a big change.

Jason is also spot on regarding the fact that in the real world late code that is perfect is useless. At my current place of work I am the only developer. Even so I have to strike a balance between "good" code and code that is ready to test something even if it has some hacks to make it work. Believe me, that happens often. In fact, it just happened this past week when we had to ship 10 units in a hurry, and I had to do a number of code hacks on the fly. Everybody was working their butt off to make that happen, and it was expected that the test software I wrote woud work so they could get the units tested. There's also the fact that there's about 20 more units waiting in the wings. Was what I did "perfect" or "polished"? Heck, no. But it worked and we were able to get 10 units tested one day early. Do I mind? No, because I'm a realist, and my co-workers understand that while I strive to write good code, they know they can count on me being able to provide them a solution quickly even if it's not "polished". 

I'm not telling you the above little ditty about last week's events because I'm trying to stroke my own ego. I'm telling you this because in the end what matters is that your co-workers can count on you and you can count on them. I do want to make it clear that this doesn't mean that you subjugate yourself to be a lapdog. The worst thing you can do is to simply "play along". That's how we end up with products like Windows. Let me recount another little ditty: A number of years ago I was looking for a job and I interviewed with a company that had a position that was perfect for me. During the interview I asked how they would respond to a scenario where I would look at the way they were doing their testing and said that they really should be doing it this way. The basic response I got was they didn't want to "rock the boat". I knew right at that instant the interview was over as I had no intention of working for them. They actually ended up offering me the job, but I turned them down. When the manager contacted me by email wondering why I had turned them down I specifically told him about the scenario I had brought up, and that the reason I asked the question was to determine how flexible they were to new ideas. I told him his answer clearly indicated they were not flexible at all, and he understood and respected that and realized I was right.

So, to make a long story short: hang in there, and try out little things at the start. Get the feel to how the other members of your team like to work. Perhaps you can suggest having a group meeting every once in a while where everybody gets together to discuss coding techniques and looks over previous work and everybody (including you) has a chance to weigh in on what's good, and what can be improved. 

[JÞB]

One of the things that you need to consider is the vast array of code intentions.  The software you write to perfom a minor lab experiment today is not going to have the same software requirements as an application that monitors a neuclear reactor.  Certainly, "code hacks" infest a lot of workplaces and generally they can do what is necessary for the company.  When you need applications that are "maintainable," "bullet-proof," and tracable you need to up the game from "code that can be used" to "quality product."

The prevalence of "spaghetti-code" in LabVIEW is a common complaint heard everywhere as an argument against using LabVIEW over a "REAL" programming language.  This is not a flaw of LabVIEW however - it mearly demonstrates that LabVIEW is so easy to use that you do not need a software engineering degree to create a useful application.  IMHO NI should co-opt GEICO's slogan "So easy a cave-man can do it"- and understand it.

 But you are exactly correct to point out that bad code is just that - unprofessional.  The closest annalogy I can think of is Karaoke.  Singing is easy and almost everyone can do it however, few people would pay to attend the local karaoke bar.  True artists, on the other hand, command large audiences happy to pay to hear them perform.  True LabVIEW developers code by first understanding the software development process and write code to meet a requirement specification. 

The way to implement this in a new business (your situation) is to first truely understand the companies needs then, and only then, propose a software development  plan that addresses the business case of the company.

[GregFreeman]

---

 The worst thing you can do is to simply "play along". That's how we end up with products like Windows.

---

LOL. I wish I could give you all ten Kudos and mark all replies as solution. I'm really happy with the responses and how you all put stuff in perspective. Thanks, and I'm excited to be back on these forums now that I am finally working with LabVIEW again. Anyone using labview and not utilizing these forums is really missing out.They are a great help.

Message Edited by for(imstuck) on 10-17-2009 02:53 PM

[jcarmody]

I've been in your position and was able to influence the direction of my company.  I started using the JKI State Machine when it was first released, spent some time learning to use it and then started showing the others how to quickly build a proof-of-concept program that will be readable/maintainable/extendable too.  I was able to convince (convert) the three other main developers of the value of my approach and was eventually able to convince our new manager enough that he's pushing it as a major part of our standardization plan with the Product Development group.  Our CVI guy is also excited about using it and it's being included as a requirement for outsourced projects.

Whether you do what I did or not, I think you need to offer something that will improve the quality of your group's software while making it easier for the developers to do their jobs.  I believe a solid framework/template is a good first step.

[LV_Pro]

I'll jump in with my two cents worth as well. As a contractor I have worked at a number of various companies and seen just about every style (or no style!) imaginable. At some I have been asked to make suggestions to improve their process, at one I was told that the they knew the "template" they were using was flawed, but that I was to work within it. I have also come in and been asked to make changes to existing code, some of which was truly painful to look at. 2 1/2 screens wide, with every one of the sub-vi icons essentially looking the same. Still have nightmares! One thing that wasn't mentioned, or I missed, is that developing some basic style "guidelines" can help in the long run, and be used even in the quick projects to make them not so "quick and dirty". Make up some basic templates, saved as .vit in the template directory, such as a basic vi with error handling, with templated comments in the documentation part of the VI properties. Get in the habit of commenting the code, particularly those parts that may not be entirely obvious, helps even you when you have to revisit the code later and scratch your head trying to figure out how that part works. Put in comments that may have a "searchable" string (I use my initials   pwm - blah blah ...) where there are parts that may not be complete, or that you may want to beef up later, so that you can do a string search at the higher level and find everywhere you wanted to go back when you had time. An example is where you might hard code something with a constant in the heat of the battle, but want to have as a variable read in for different use cases, so you put a comment to that effect and when the 10 units are tested and you have a couple of minutes (or more!) to go back you can include them in the stuff that is loaded from an ".ini" file on startup.

As to changing the culture of the group, well it might be just doing the best you can, and if someone has to modify your stuff and learns some new methods ... I can tell you it can be tough, there are some out there that can spell LabVIEW (not necessarily with the correct capitalization though) but their code, if it works, is balancing on a house of cards. 

Good luck, work on your skills, both in programming and in thriving in your workplace.

[Coq_Rouge]

 A common problem is as follows. Your project started out as a doghouse, but after several "patches".  you end up with a apartment building, but it is still built on the doghouse foundation wall. So the construction is quite shaky. So sometimes it is better to tear things down and build a new foundation wall, with brand new materials. Reusing only well documented core functions.

Another thing is that Labview often are used by not so skilled Labview programmers. Labview is marketed heavy as a tool everyone can straight from the street can use within 30 minutes. Using slogans like get measurement ready in 30 seconds (or perhaps it was 30 minutes). Labview as any software tools needs some practice to master. In order to master Labview some hands on practice is needed. Producing efficient Labview code is no learned overnight. But this is in my opinion ignored by the Labview marketing division. Some of the Labview marketing videos, have the same truth as Coca Cola Xmas commercial.  And this approach will in the long run only hurt NI. As it gasoline on fire, for people claiming that Labview is not "real programming tool"  

[GregFreeman]

So, as  if my wishes were answered, today I heard that our code needed to be optimized because it was having trouble running on laptops. Bingo! My chance to jump in. My constructive criticism based email suggested ways to change and improve things, and consisted of many of the examples I got in these replies(templates, jki state macine, and better development plans). I haven't gotten  a response back from the email  but I'm sure we will take some of your ideas to make the code more maintainable, and if not for existing code, at least use  them as guidelines in the future. As I learn new things about how to change the direction things are going related to LabVIEW I will continue to update this thread so that maybe people can learn from my process in the future. Thanks again everyone.

[Mark_Yedinak]

Well, I'll jump in a bit from the opposite point of view. Several have stated that due to time considerations they will simply "hack" out code to get it done. While there is always a need to get your product out quickly I disagree with "hacking" out quick and dirty solutions. In the long run this will only come back to byte you in the butt. Good software engineering skills do take time to develop as well as time to master. Those skills also require you to practice. However, as you begin to master them you are able to do them more quickly too. So in my opinion hacking something out is always the last resort. Part of changing the culture should also be to allow for a quality product to be delivered. I am not saying that all projects should be pushed out by months but in most cases a couple of extra days to do it right is acceptable. This is the culture that you should try to foster.

There are endless resources that clearly show that a bug in released code can be quite costly. This includes damaging your reputation for delivering quality products. As someone who not only develops code but also purchase it I can say that a vendor will quickly fall off of my list of approved vendors if I consistently receive a poor quality product. Even minor bugs can result in a poor opinion of a vendor. Consider reviewing resumes for a prospective candidate, are you going to seriously consider the one that has several typos in their resume. The same is true for software bugs.

In addition, as you develop more code you should always be considering your reuse library. Over time this will grow and you you will want this to be high quality code. Your reuse library should not consist solely of small pieces of code but also reuseable project architectures. Consider developing complete application templates. Once you start using them even simple applications can be built quickly yet still be flexible to enhance, and be feature rich (Custom menus, use of configuration files for initialization, general error handling, logging, etc.).  If you don't think long term about your code it is difficult to reach a point where you will have a significant library of reusable code. One off's may get a product out the door fairly quickly today, but if you are constantly rewriting the same code all of the time because you don't focus on reuse than are you really saving time in the long term?

I have seen many companies fall into the "it has to be delievered today or else" mentality who have encountered long term issues to realize that you always need to think ahead. As systems grow they become unmaintable and then it is nearly impossible for them to deliver new and innovative features because the code become too fragile to touch.

Message Edited by Mark Yedinak on 10-19-2009 08:07 PM