I referred to several books and articles, which I’ve listed here for your convenience.

The Association for Computing Machinery (ACM) is the primary group which promotes computing as a science and a profession.  The Turing Award from the ACM is sometimes called “The Nobel Prize of Computer Science”.  Two of my references are the acceptance lectures of Turing Award recipients.

The Dutch computer scientist Edsger W. Dijkstra was a thought leader in many areas of computer science—the theory of programming languages, software engineering, distributed computing, formal verification, et al.  His 1972 Turing Award lecture, The Humble Programmer, inspired me to write this series of blog posts and choose the word “humility” for the title.  His main theme is that writing software is a really hard task, and therefore, we have to simplify it in order to understand it.  A few of these ideas show up in an earlier Dijkstra paper, Programming Considered as a Human Activity, written in 1965.

The British computer scientist Sir Charles Antony Richard Hoare (“Tony”, or commonly in publications, C. A. R. Hoare) was the 1980 Turing Award recipient.  He is an expert in many areas of computer science, such as concurrent processing and programming languages.  He also invented the powerful Quicksort algorithm.  His lecture, The Emperor’s Old Clothes, discusses several lessons learned from his years advising on the development of different programming languages.

In 2006, Dan Ward (now a US Air Force Lt. Colonel), wrote a short manifesto about complexity and simplicity as systems get larger and larger.  The Simplicity Cycle is a thought provoking read.

In 1993, Steve McConnell wrote the nearly 900-page book, Code Complete. (A second edition came out in 2004.)

Code Complete brought together many practical programming ideas into one volume… design, data structures, coding constructs, style, quality, debugging, testing, software engineering, performance tuning, and many other topics.  His section on Software Craftsmanship was another source of inspiration for this series of blog posts.

In 1971, Gerald Weinberg finished his book, The Psychology of Computer Programming.  This book, like Dijkstra’s work referenced above, wanted to consider programming as a human activity.  Besides introducing the concept of egoless programming, it’s got several entertaining anecdotes about software development. The author updated it in 1998 with a silver edition, which added commentary about how things had changed in 25 years, and how they had stayed the same.

Nancy pointed me to Kent Beck’s book, Implementation Patterns, published in 2007.

Though written for Java programmers, this book emphasizes readability of code, and knowing the “why?” behind good programming habits.

There is no magic to writing code other people can read. It’s like all writing—know your audience, have a clear overall structure in mind, express the details so they contribute to the whole story.

—Kent Beck, Implementation Patterns

Can you recommend other books or articles in this theme? Post them as comments below.

Programs, like any other human-made objects, are designed—or should be designed—with a definite lifespan and scope of application in mind.

…a program should have neither over-designed or under-designed parts. Yet it is an occupational disease of programmers to spend more time on those program parts that present, for some reason, the most intellectual challenge rather than on those that require the most work.

…each program has an appropriate level of care and sophistication dependent on the uses to which it will be put. Working above that level is, in a way, even less professional than working below it. If we are to know whether an individual programmer is doing a good job, we shall have to know whether or not he is working on the proper level for his problem.

— Gerald Weinberg, The Psychology of Computer Programming

Nancy and I recently got into a discussion about the best programming approach for a particular application. We both had in mind that maintainability of the application was very important. As is common for the two of us, we wanted to take different approaches to get to the same place. She proposed on OO plugin approach that I thought was more complex than needed. As we talked about it, I realized we had slightly different ideas of what “maintainability” meant.

I was thinking that the need for maintainability emphasized simplicity. She was looking down the road a bit, thinking the customer was going to need more flexibility than would have been afforded with my approach. Thus, her more scalable solution was going to be more maintainable in the long run.

Who is right?

Well, I am, of course. The customer isn’t asking for scalability right now. So Nancy is speculating. I’d rather wait until the customer asks for (and convinces me she needs) the scalability before I go to the trouble of writing it.

To be fair, Nancy’s approach is just as right, and she may know what the customer wants better than I do—and maybe even better than the customer does. Nancy may also be confident that she can add the scalability without adversely affecting the initial development time or the maintainability of the code. This seems like a prime opportunity to go ask the customer for clarification on their future plans.

This example also illustrates another key point. Nancy and I both have enough LabVIEW experience and skill to design and build an OO-based plugin architecture. I made a conscious choice to exclude it. Nancy made a conscious choice to include it. If we didn’t know about OO plugin architectures, we would not have a choice to make—we would have left out the scalable solution because we knew no better.

That right there is why I want you to become a Certified LabVIEW Architect. I want you to know enough about LabVIEW that you can decide when to use—and when not to use—the many tools that are available. Don’t let a lack of knowledge of advanced LabVIEW concepts make the decision for you.

Going back to the quote at the top of this post about using an “appropriate level of sophistication”, I’m reminded of another discussion I had with an engineer at NI. First, let me show you an example which in a loop, acquires 200 samples of analog data and scales the data based on the value of a front panel control. The acquisition timing is configured in the task in MAX. A novice programmer might program it this way… (Click the images to see full-sized versions.)

The conversation with my colleague, who is a very fast LabVIEW programmer, went something like this… “Polling user interfaces are bad. You should use an event structure. Something like this example…”

There’s a good chance that the novice programmer wouldn’t have known how to build this event-driven program. But here’s my question for the expert programmer… “Why didn’t you write it the simple way?”

In this case, the novice programmer is me. I do have the skills to build an event-driven program for this application, but I didn’t think it was appropriate. What’s an example of something I give up by not using an event structure? If my read hangs waiting for a trigger, then the stop button takes up to ten seconds to stop the VI, while I wait for the timeout on the read. What if that’s not acceptable? What if I needed to respond in less than five seconds? Before diving into a rewrite using event-driven programming, I’d first ask whether I could just lower the timeout on the Read to be five seconds. Maybe I know my trigger will never take that long without it being an error.

There are ways I can make this program more robust, more responsive, more scalable, more capable. But why do that if those aren’t requirements? Mandates such as “don’t write polling user interfaces” are too stark. Fortunately, my colleague has backed off of his tough stance against polling user interface loops. He doesn’t like them for most user interfaces, but he sees that there are times when they are the most appropriate solution.

A note about frameworks… Nancy has been thinking about software frameworks recently. (I’m hoping she’ll write a blog post about it.) Lifting from the entry in Wikipedia about software frameworks…

A software framework is a universal, reusable software platform used to develop applications

It goes beyond just a reuse library or a design pattern which provide only elements of an application. A framework imposes a structure on the entire application. One such framework is the Actor Framework, which we started shipping in LabVIEW 2012. There are many other frameworks for LabVIEW applications.  Some companies have developed their own for their typical applications.  Some are shared for the community to use. In the theme of being “too clever”, I have seen some customers apply their favorite framework to every programming problem they have. If all you have is a hammer, everything looks like a nail. One of the traits of a good Certified LabVIEW Architect is that they have more tools in their toolbox, and know when to use each appropriately. The Actor Framework, as an example, is one way to architect an application when you have a bunch of independently running processes that need to communicate. If you have an application that doesn’t involve a bunch of independent processes, I wouldn’t try to force my application to the framework. Instead, I’d recommend finding or creating a more appropriate framework.

If you’ve made it this far, thank you for sticking with this long post. As an old programmer, I have a fair number of battle scars (also known as “experience”) which I sometimes take for granted. I make many programming decisions almost without thinking. Some are just a force of habit, and I might not stop and teach these habits explicitly, and this blog post is an attempt to capture and share a few of those thoughts.

I would love to hear your feedback on this series. Let me know what you think.

You can also learn by looking at other peoples’ code.  We put a lot of effort into the LabVIEW 2012 Templates and Sample Projects. I’d recommend fully understanding the simple state machine and queued message handler. The finite and continuous measurement sample projects are a great place to start, too.

In LabVIEW 2013, we’re making a concerted effort to improve the examples we include.  Some of the examples in 2012 had been written years ago, and no longer represent good LabVIEW programming practices.  You can also study how others have written various design patterns in LabVIEW.

Are you involved with your local LabVIEW user community?  You have many LabVIEW peers in other companies, and they’re a great resource for learning new ideas and reviewing yours.  Some cities have both beginner and advanced user group meetings.  The most advanced user forums are the annual CLA Summits held each spring.  You have to be a Certified LabVIEW Architect to attend, and more than one CLA said that access to the summit is the reason he became a CLA.  We highly recommend finding some peers inside or outside your company who can help you learn.

Here’s a question I get a lot when I talk about code reviews with my customers…

What if you are the only programmer on your team?

I have to admit that I’m not familiar with this situation. I have been fortunate enough to be in a great organization with a bunch of software engineers always available to review code. But if I were the only programmer, here are some ideas…

• Find someone else in your company, even if they aren’t on your team. Take them to lunch, buy them beer—and absolutely offer to review their code in exchange. Create a virtual team where everybody can share their LabVIEW knowledge. Do you have an internal LabVIEW user group meeting? Reviewing code there is a great place to start.
• Teach someone LabVIEW. Do you have a hardware engineer or a mechanical engineer who doesn’t know LabVIEW? Or a software engineer who only knows one of those archaic text-based languages? Ask them if they’re willing to learn enough to review your code. Tell them you’ll explain it enough detail that they can figure it out. Yes, it’ll be painful at first, but maybe you’ll win a few LabVIEW converts along the way.
• Consider hiring an Alliance Partner as a LabVIEW Consultant for a few hours.

When I was telling Nancy about this blog post, she suggested that you could just create an invisible friend and explain the code to him. I think most of us can find someone real to help, but it did remind me of another anecdote from the book about a side effect that happens when you plan on having your code reviewed.  This is about an individual who took part in a programming study…

… one of these subjects—they were all students on a special three-month course—happened to come from a group that practiced egoless programming. At a certain point, he came to me and said that he had reached the point in his work where he needed someone to look over what he had done. As the object of the experiments was not to study differences between group work and individual work, I was forced—against my own beliefs—to request that the subject try to proceed without outside assistance, which would only add to the variance of the experiment.

As a sidelight to this incident, it should be noted that this programmer’s work seemed to the evaluators to be better organized and better executed than the other four programmers working on the same problem. In discussing this question with him, he raised the point that he had worked throughout as he always did in his own group—always with an eye to making the program clear and understandable to the person or people who would ultimately have to read it. This insight indicates that all the advantages of egoless programming are not confined to the detection of errors.

— Gerald Weinberg. The Psychology of Computer Programming

In other words, if you write your code with the expectation that it’s going to be reviewed, you’ll write better code.  And that leads to another important idea.  Even if you don’t expect others to read your code, don’t forget that you are almost certainly going to read your own code at some point in the future.  It may be tomorrow, when you pick up where you left off today, or it might be a year from now, when something goes wrong with your deployed application, and your end user needs a problem diagnosed and fixed ASAP!  I have code inside of LabVIEW that I wrote years ago. Every now and then, I have to look at it.  It sure helps to to be looking at clean, well-commented code when I’m learning it all over again.

Enough about reviewing code.  What else can we do to be better programmers?  More coming up in part 5.

A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct—even if this means the oversight of errors which are monstrous to another eye.

— Gerald Weinberg. The Psychology of Computer Programming

In this book in 1971, Dr. Weinberg described the concept of “egoless programming”, using a cooperative approach to programming.  One of the main points of his book is that programming is better with teams that share their ownership of code.  I didn’t know this style of development had a name, but this is what we’ve practiced on the LabVIEW R&D team since the beginning.  The more modern “agile” software development methods have their roots in egoless programming.

There are a bunch of great anecdotes in the book, many of which are still relevant 40 years later.  Here’s a great story that helps explain more about egoless programming…

A programmer (“Bill”) was responsible for writing an important section of code at the heart of a simulation system.  This section of code was a loop that consisted of just thirteen lines of machine code.

…when he finally reached the point of some confidence in it, he began looking for a critic—the standard practice in this programming group.

Bill found Marilyn B. willing to peruse his code in exchange for his returning the favor. This was nothing unusual in this group; indeed, nobody would have thought of going on the machine without such scrutiny by a second party.

… His value system, when it came to programming, dictated that secretive, possessive programming was bad and that open, shared programming was good. Errors that might be found in code he had written—not “his” code, for that, terminology was not used here—were simply facts to be exposed to investigation with an eye to future improvement, not attacks on his person.

In this particular instance, Bill had been having one of his “bad programming days.” As Marilyn worked and worked over the code—as she found one error after another—he became more and more amused, rather than more and more defensive as he might have done had he been trained as so many of our programmers are. Finally, he emerged from their conference announcing to the world the startling fact that Marilyn had been able to find seventeen bugs in only thirteen statements. He insisted on showing everyone who would listen how this had been possible…

Marilyn, at the same time, did not feel any false confidence in her own work on the problem, for—she reasoned correctly—-where there had been seventeen errors, there were probably a few more… while Bill was giving everyone an enormous laugh at his expense, Marilyn and others managed to find three more errors before the day was over.

As an epilogue to this incident, it should be noted that when this code was finally put on the computer, no further errors were found, in spite of the most diabolical testing possible. In fact, this simulator was put into use in more than a dozen installations for real-time operations, and over a period of at least nine years no other errors were ever found. How different might have been the story had Bill felt that each error found in that code was a wound in his pride—an advertisement of his stupidity.

— Gerald Weinberg. The Psychology of Computer Programming

So how do you put this into everyday practice?  I can sum it up this way… Don’t work in isolation.  Here’s one major theme…

Review your code with others.

This is the way we do it in LabVIEW R&D.  Approximately* all of the code that anyone submits to our source code control system is reviewed by at least one other person.  (* There are exceptions for fixing misspellings in comments and other simple changes.)

It takes courage to bare your code to others. You have to be honest and not hide anything. It seems there’s always code that could have been written and documented better, designs that could have been more elegant, and error checking that could have been cleaner, weighed against getting the feature or bug fixes done in a timely manner.  But we do it anyway.  Remember, we’re reviewing code, not reviewing the person.  It’s not about your ego; it’s about creating better software.  I know that in some organizations, this will be a big culture shift.

Reviewing code has multiple benefits.  It builds stronger teams, which build stronger, more maintainable applications…

• A reviewer is more likely to see bugs than I am.  Sometimes you are so familiar with your code that you are blind to obvious bugs.  There’s also the benefit that more bugs are caught early, before they are submitted to the main branch in the source code control repository.
• It helps ensure that my code is readable and explainable.  I like to sit with my reviewer and go through the code with her.  If I have trouble explaining it, there’s a good chance the code isn’t written well and I might need to rethink it.  And on more than one occasion, I’ll realize I have a bug in my own code when I see that the code isn’t matching my verbal explanation.  Other people like to have their code reviewed “offline”—“Hey reviewer, here’s my code.  Get back to me.”  This forces you to document it well enough that the reviewer will understand it without additional explanation.
• Someone else learns something about the code.  If the author of a change goes on vacation and I have a question about the code, I can try to find the person who reviewed the changes.  They may not know the code as deeply as the author, but they might be able to explain the code well enough for me to figure out my question.
• It encourages reuse.  A reviewer might know that the team already has a function that does what you’re trying to submit.  Or, I might remember that I reviewed a piece of code that’s just like a function I need now.  I can find and reuse the code, rather than write my own.
• It’s a great way for the team to learn good coding practices and style.  This is how new programmers learn the team’s style.  A reviewer can remind you if the style guidelines call for a particular connector pattern, error handling scheme, or documentation style.
• The teaching works both ways.  A junior developer can learn from an experienced reviewer.  A senior developer can learn new tricks from a junior reviewer.  (And for completeness, a senior developer may want to find a senior reviewer if a bug fix is particularly difficult or mission-critical, and it’s usually not a great idea to have a novice developer use a novice reviewer.)
• It forces developers to have at least a few social skills.

One more comment on reviewing all code…  I’ve heard of teams that only review difficult or problematic (buggy) code.  A major downside of this is that junior engineers only learn from difficult and buggy code—i.e., they are learning from the poorest examples.  Conversely, I’ve heard of developers who hide the ugly code, and just want their best code reviewed.  Reviewing all code means everyone gets a more balanced view of the quality of the project.

For more on code reviews, see our NIWeek 2012 presentation, which we plan to present again at NIWeek 2013.

More ideas coming up in part 4.

Truly excellent programmers learn how to work and play well with others. Writing readable code is part of being a team player. The computer probably reads your program as often as other people do, but it’s a lot better at reading poor code than people are. As a readability guideline, keep the person who has to modify your code in mind. Programming is communicating with another programmer first and communicating with the computer second.

— Steve McConnell, Code Complete

The majority of the cost of software is incurred after the software has been first deployed. Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.

— Kent Beck, Implementation Patterns

Bringing this back to my remark about spaghetti code that began part 1, let me include this sentence from Edsger W. Dijkstra, one of the giants in the field of computer science..

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

— Edsger W. Dijkstra, The Humble Programmer, ACM Turing Lecture 1972, EWD340

Steve McConnell, expands on this idea…

The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.

— Steve McConnell, Code Complete

Let’s face it, though, our customers work on complex problems that often need complex solutions.  But, I carefully did not use the word “complicated”.  Complex and complicated do not go hand in hand…

“Complex” and “complicated” may sound similar, but they are in fact two very different beasts. Complexity is often essential. Certain topics, issues, activities and missions are inherently complex and there’s nothing wrong with that. But complicatedness involves unnecessary complexity. It’s caused by the addition of non-value-added parts, of gears that turn without reason or grind against other gears.

— Dan Ward, The Simplicity Cycle

The LabVIEW source code is complex; no doubt about it.  But, we strive to keep it from being complicated.  The parts that are complicated are ones we struggle with—often because we haven’t figured out how to make them simple, yet.  Paul Austin, another old-timer on the LabVIEW R&D team, encourages young engineers to find the simplest solution to the problem they are trying to solve.  Great advice.

The quote from Major Ward above is from a short manifesto that’s definitely worth a read.  The main point is that as a system evolves, it either collapses from its own complexity, or it thrives because of its simplicity.

Two and a half decades earlier, Tony Hoare (another giant of computer science) said the same thing…

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways.

— C.A.R. Hoare, The Emperor’s Old Clothes, ACM Turing Award Lecture 1980

Some of the code in LabVIEW is over 20 years old.  We didn’t know then it would still be with us after 20 years, but we strive to make our code maintainable enough that it could be.  If you want to create code that’s built to last, make it as simple as possible.

In part 3, I’ll talk about things you can do to create better, more maintainable code.

A little over 25 years ago, I started working at National Instruments as an entry-level software engineer.  I received an outstanding education as a computer scientist from the University of Texas at Austin, where I was able to interact with some of the greatest minds of the Computer Sciences… Woody Bledsoe, Edsger W. Dijkstra, C.A.R. Hoare, to name a few.  Besides learning from great teachers, I learned how to become a better teacher.  Teaching a really difficult subject (assembly language, in my case) for several semesters to college sophomores will make you a better teacher, and will make you a master of the subject as you explain concepts a dozen different ways to try to get it across.

Soon after starting at NI, it became clear to me that one of the shortcomings of my formal university education was that I didn’t have much experience writing code.

Wait.  What?  You got a degree in computer science and don’t know how to program?

I didn’t quite say that.  Sure, I knew algorithms, data structures, operating system concepts, and I was immersed in the field of artificial intelligence, especially automated theorem proving.  I could write small- to medium-sized programs in a variety of different programming languages.  What I didn’t learn in the classroom was how to be a professional programmer who could write large, robust, maintainable programs.  It just wasn’t needed in our assignments—the lifetime of a class programming project was at most a semester, and group programming projects were pretty rare.

I learned to program outside the classroom.  I was active in the open source community before we called it the open source community.  I collaborated on several projects, mostly irrelevant now, but which were important to the greater community at the time.  I was collaborating with people I would never meet, but who shared a common goal of writing useful programs for problems we all shared.  And guess what?  It encouraged us to write robust, maintainable code.  If you didn’t, you were (nicely) called out on it—often by having someone else document your code for you, or sometimes rewrite it in a better way.  The better the code, the more likely someone would add to it—new features, better performance—whatever was needed.

The other place I learned to program was on the job in the LabVIEW R&D team.  I had the best mentors.  Steve Rogers and Rob Dye really stand out.  They are both software architects still on the development team.  Part of the culture in LabVIEW R&D is to have some humility when it comes to the code.  While you might be responsible for a section of code, you don’t “own” it.  Steve says that the only person who can rightfully “own” code in LabVIEW is Jeff K.

The LabVIEW source code is communal—anybody (on the team) can touch any part they need to.  If I need to change how a function is called, then it’s my responsibility to update every place that it’s called, wherever that code is.  (Or come up with a way for callers to be fixed automatically.)  Territorialism (“stay out of my code”) is not tolerated.

This turns out to be a really good approach to software engineering, and I want to use a couple of blog posts to explain why.

My team is a fan of the book Code Complete, by Steve McConnell.  I first read this back in the mid-1990’s, as we were growing our development team and growing our processes to match.  I was recently rereading part of it, and ran across a chapter on “Personal Character”.  One of the key points of this chapter…

“Your personal character directly affects your ability to write computer programs.”

In part 2, I’ll dive a bit deeper on why I think this is true, and share some ideas from my experience that will help you become a stronger programmer.

The CLA Summits are like a very intense LabVIEW User Group Meeting.  We are having lots of great discussion, generating lots of new ideas, and we’ve met several new friends.  A big thanks to NI France for hosting us.

Here’s a photo of Jeff Kodosky giving opening remarks at the Summit.

We’ve had tremendous growth at the CLA Summits—record attendance in both Austin (over 100 CLAs) and in Paris.  Keep working on your LabVIEW CLA certification, so we can see you at next year’s summits.

Here are some of the new features…

• Updated user interface, including a “ribbon” interface and fixes for the mouse-wheel
• Improvements for continuous monitoring applications and for selecting which data to capture.  The old DETT would collect data until it ran out of memory.  Now, you can log to a file or discard data to make room for new data.
• Improved searching for text in the traces
• The ability to compare traces

The new DETT supports LabVIEW 2010 and later; you do not have to upgrade to the latest LabVIEW.  Note, however, that the new DETT will automatically uninstall your current DETT.  If you want to downgrade, you will need to uninstall the beta and install the old version.  Also note that you can load your old trace files into the new DETT.

Sign up at the Beta Program Resource Center.  Your application will be reviewed and you will be informed by email once you’re approved.  We would like to have all of your feedback by May 15, 2013.

• Session Slides
• Issue Tracking Spreadsheet Template
• Sample Code Review Checklist

If you have any questions about these, please comment.

There are soooo many great sessions.  If you’re not coming to NIWeek, you’re missing the year’s best event for learning about LabVIEW.  Come prepared to take a bunch of notes, network with a bunch of really smart people, and learn about a bunch of new technology.

First, let’s talk about the important stuff…

Food and Drink

If you’re in town early, there’s a Sunday (August 5) informal get together at the Gingerman Pub.  It’s near 3rd and Lavaca, just a few blocks from the convention center.  Since it’s informal, there’s no official start time; people just show up in the evening when they get into Austin.  I’ll be there by 8 or 9 PM or so.

Tuesday night is the annual LAVA barbecue.  This is also a non-conference event.  (In other words, you have to pay separately.  Click the link to register.)  All the cool kids will be there.

Wednesday night is the main NIWeek conference party at the Moody Theater (where Austin City Limits is filmed).  It’ll be a fun, crazy dance party.

Keynotes

The keynotes each morning are a great way to see an overview of all of the technology we’re introducing.  Here are a few highlights…

TUESDAY, AUGUST 7
Eric Starkloff, Vice President of Product Marketing for Test and Industrial Embedded

Watch Eric Starkloff and NI engineers unveil the latest products, technologies, and customer applications demonstrating graphical system design in cutting-edge measurement and control systems.

WEDNESDAY, AUGUST 8
Jeff Kodosky, Cofounder and Business and Technology Fellow

Hear from Jeff Kodosky, the coinventor and “father” of LabVIEW, as he shares fundamental programming concepts vital to meeting the most demanding application challenges during the next 25 years of graphical system design.

THURSDAY, AUGUST 9
Dr. Thomas R. Kurfess, Assistant Director for Advanced Manufacturing for the White House Office of Science and Technology Policy, Professor and BMW Endowed Chair of Manufacturing at Clemson University

Listen as Dr. Thomas Kurfess talks about his work with scientists and policymakers in various executive branch agencies that support advanced manufacturing, such as the Commerce Department’s National Institute of Standards and Technology and the Department of Defense.

Industry Summits

There are a half dozen industry summits on a variety of topics, including Aerospace/Defense, Big Physics, and Energy Technology.  One of my favorites is…

Robotics and Autonomous Vehicles Summit
This summit unites the world’s top roboticists, researchers, design engineers, and domain experts working on robotics applications. With in-depth technical sessions and corresponding live demonstrations at the Robotics Pavilion on the expo floor, you can learn how to apply the latest technology from real-time devices, field programmable gate arrays, and graphical and textual programming to design robotics systems faster than your peers.

We’ll have a bunch of cool robots on the expo floor and in the keynotes, and several technical sessions.

Planet NI Special Event

Planet NI is a National Instruments initiative for emerging countries. We’re having a special event with polar explorer Robert Swan…

WEDNESDAY, AUGUST 8

Robert Swan, Explorer

Nurturing Innovation in Emerging Countries: Reducing Social Disparity through Technology

Although emerging countries account for 75 percent of the world’s population and 30 percent of the world’s economy, thousands of engineering students and professionals in these countries have little to no access to PCs, the Internet, instrumentation, or software tools.
Through the Planet NI program, National Instruments is working to provide access to graphical system design technologies for innovators in emerging countries. These entrepreneurs can then develop technology-based companies that provide solutions for solving local economic, social, and environmental challenges.
In this forum, you can hear directly from the world’s top motivational speaker, environmentalist and global leader Robert Swan, as well as small and medium enterprise (SME) business owners, non-governmental organizations (NGOs), and educators from countries such as Africa, Latin America, Arabia, India, and South East Asia. You can learn how access to technology is providing job opportunities, reducing social disparity, and helping students in rural and impoverished areas to innovate and participate in experimental learning.

Training and Certification

How well do you know LabVIEW?  How does your boss measure your LabVIEW skill?  Throughout NIWeek, NI has several heavily discounted certification exam opportunities, including free preparation sessions.

We also have several discounted training courses that we’re offering just before NIWeek.

Technical Sessions by Field Architects

Because this is our blog, we get to highlight our sessions first.

As with all NIWeek sessions, the schedule and room assignments might change.  Be sure to check for daily updates.

Hands-On: Code Review Best Practices

8/7/12 (Tuesday 7th), 10:30 AM – 11:30 AM, 18 B

Nancy Hollenback and Brian Powell, Field Architects

LabVIEW R&D engineers review all (yes, ALL) code that goes into the product and encourage you to do the same. In this session, examine best practices and learn how your team can use these ideas.

 

VI Shots “Live”

8/7/12 (Tuesday 7th), 4:00 PM – 4:30 PM,Technology Theater on Expo Floor

Michael Aivaliotis, and several panelists, including Brian Powell

Come watch the VI Shots biweekly podcast recorded LIVE from the technology theater. Join the discussion with host, Michael Aivaliotis and become part of the LabVIEW ecosystem. Michael will be moderating a panel discussion with prominent members of the LabVIEW community on a wide range of topics focused on taking your LabVIEW skills to the next level. Audience participation is encouraged, so bring your questions!

 

Network Streams – More Than Just Streaming

8/8/12 (Wednesday 8th), 1:00 PM – 2:00 PM, 16 A

Nancy Hollenback, Field Architect, National Instruments

The Network Streams API simplifies the streaming of buffered, lossless data between two computers or between a real-time target and a host PC. It also supports messaging between two LabVIEW targets or across application instances. Explore the mechanics and common mistakes of using this API and learn ways to abstract the API for use across a project team.

 

Everything You Ever Wanted to Know About Functional Global Variables

8/8/12 (Wednesday 8th), 3:30 PM – 4:30 PM, 19 B

Nancy Hollenback, Field Architect, National Instruments

As a longtime foundational design pattern in the LabVIEW community, the functional global variable (FGV) meets many common challenges but can also be overused. Join this discussion of best practices for global data storage and the transition from FGVs to data value references.

 

Design and Implement an Object-Oriented Instrument Abstraction Layer With UML and LabVIEW

8/8/12 (Wednesday 8th), 4:45 PM – 5:45 PM, 16 A

Charlie Knapp, Field Architect, NI, Orange County and JPL, SoCal

Learn how to design a simple object-oriented oscilloscope abstraction layer in Unified Modeling Language (UML) and implement this layer in LabVIEW. The design is extendible to include other instrument types, and the LabVIEW source API works with multiple models from different vendors, other A/D devices, and simulated waveform acquisition tools.

 

The What, Why, and How of a Network Connection Manager

8/9/12 (Thursday 9th), 10:30 AM – 11:30 AM, 19 B

 

Mike Bailey, LabVIEW Technical Evangelist, National Instruments

Learn what a network connection manager is, why you need one in your system, and how you can construct it in LabVIEW. Also explore the technical details of the build up as well as connection protocols, management , and methods. Lastly, see how to use the API to integrate this into your own system.

Mike Bailey is a Certified LabVIEW Architect in the United Kingdom.  He recently switched from a Systems Engineering role to work on LabVIEW adoption and proficiency among our European accounts.

A Couple of Especially Intriguing Sessions

Poland’s Fastest LabVIEW Programmer

8/7/12 (Tuesday 7th), 2:00 PM – 2:30 PM, Technology Theater on Expo Floor

Andrzej Przybylak Veritech Sp. z o.o.

Andrzej Przybylak has competed in coding competitions in Poland but now he is traveling to NIWeek 2012 to take on Darren Nattinger, reigning World’s Fastest LabVIEW Programmer, for the main title. Come listen to his story of LabVIEW coding challenges in Poland and how he is preparing for his contest against Darren.

 

Worlds Largest User Group

8/7/12 (Tuesday 7th), 6:15 PM – 7:15 PM, Technology Theater on Expo Floor

Kelly Hunka National Instruments

Help us make history by attending the World’s Largest User Group Meeting. This event during the Block Diagram party will include an award ceremony for incredible user group leaders as well as a LabVIEW technical presentation from a LabVIEW Champion. This event has all the great things that make up as user group meeting: technical content, networking opportunities, and of course fun. You won’t want to miss it!!

More Technical Sessions

While all NIWeek sessions are usually excellent, we want to highlight a few other sessions we think will be great.  See the NIWeek Session Catalog for details about each of these.

Tuesday

Secret Sauce: Non-LabVIEW Tools to Make You a Better LabVIEW Developer

8/7/12 (Tuesday 7th), 10:30 AM – 11:30 AM, 12B

Justin Goeres JKI

 

Architecting Embedded Control and Monitoring Applications

8/7/12 (Tuesday 7th), 1:00 PM – 2:00 PM, 12B

Meghan Kerry, LabVIEW Product Manager, National Instruments

 

LabVIEW Classes: The State of the Art

8/7/12 (Tuesday 7th), 2:15 PM – 3:15 PM, 19A

Stephen Mercer National Instruments

 

Developing System Components From Design Patterns on the Discovery Channel Telescope

8/7/12 (Tuesday 7th), 2:45 PM – 3:15 PM, Ballroom E

Paul Lotz Lowell Observatory

 

LabVIEW 2012 Advanced Design Templates and Sample Projects

8/7/12 (Tuesday 7th), 3:30 PM – 4:30 PM, 19A

Elijah Kerry, Senior Product Manager, LabVIEW, National Instruments

 

State Pattern Implementation for Scalable Control Systems

8/7/12 (Tuesday 7th), 4:45 PM – 5:45 PM, 12A

Paul Lotz Lowell Observatory

 

Software Engineering Best Practices for LabVIEW

8/7/12 (Tuesday 7th), 4:45 PM – 5:45 PM, 19 B

Elijah Kerry, Senior Product Manager, LabVIEW, National Instruments

Wednesday

LabVIEW Object-Oriented Design Process for Hardware

8/8/12 (Wednesday 8th), 10:30 AM – 11:30 AM, 16 A

Marcus Johnson Symbio

 

Hands-On: Explore Tools to Customize LabVIEW

8/8/12 (Wednesday 8th), 2:15 PM – 3:15 PM, 18 D

David Ladolcetta, LabVIEW Tools Network Engineer, National Instruments

 

Parallelizing the Unparallelizable

8/8/12 (Wednesday 8th), 2:15 PM – 3:15 PM, 16 A

Christian Altenbach UCLA

 

Hands-On: Software Engineering With LabVIEW

8/8/12 (Wednesday 8th), 3:30 PM – 4:30 PM, 18 D

Elijah Kerry, Senior Product Manager, LabVIEW, National Instruments

 

Hands-On: Actor Framework

8/8/12 (Wednesday 8th), 3:30 PM – 5:30 PM, 18 C

Stephen Mercer and   Allen Smith, National Instruments

 

Subversion and LabVIEW: Tips, Tricks, and Pitfalls

8/8/12 (Wednesday 8th), 4:45 PM – 5:45 PM, 19 B

Buddy Haun VirtEx LLC

Thursday

A Scalable Plug-in Architecture for Monitoring Distributed Real-Time Applications

8/9/12 (Thursday 9th), 10:30 AM – 11:30 AM, 16A

Fabiola De la Cueva Delacor

 

Tips and Tricks to Speed LabVIEW Development

8/9/12 (Thursday 9th), 10:30 AM – 11:30 AM, Ballroom E

Darren Nattinger National Instruments

 

Hands-On: Inside the LabVIEW 2012 Core Templates

8/9/12 (Thursday 9th), 10:30 AM – 11:30 AM, 18 D

Elijah Kerry, Senior Product Manager, LabVIEW, National Instruments

 

Custom Code Deserves Custom Analysis

8/9/12 (Thursday 9th), 1:00 PM – 2:00 PM, Ballroom G

Elaine Ramundo Bloomy Controls, Inc

 

Fire and Forget: Bulletproof Builds Using Continuous Integration With LabVIEW

8/9/12 (Thursday 9th), 1:00 PM – 2:00 PM, Ballroom E

Omar Mussa, Professional Services Manager, JKI

 

XControls in Theory and Practice

8/9/12 (Thursday 9th), 2:15 PM – 3:15 PM, Ballroom E

Michael Porter Lime Instruments Inc

Alliance Day Sessions

NIWeek starts a day earlier for our Alliance Partners.  Here are a few great sessions on Monday.

Using Practical Examples in LabVIEW to Move From Programming Basics to Advanced Architectures

8/6/12 (Monday 6th), 9:00 AM – 9:30 AM, Ballroom C

Piotr Maj AGH University of Science and Technology

 

Introduction to the Actor Framework

8/6/12 (Monday 6th), 10:00 AM – 10:45 AM, 18 D

Stephen Mercer National Instruments,   Allen Smith, Senior Systems Engineer, National Instruments

 

Advanced Error Handling in LabVIEW

8/6/12 (Monday 6th), 11:00 AM – 11:45 AM, 17 A

Ryan King, Senior Systems Engineer – Industrial Embedded, National Instruments

 

Hands-On Session – Actor Framework

8/6/12 (Monday 6th), 1:00 PM – 3:00 PM, 18 D

Allen Smith, Senior Systems Engineer, National Instruments

 

Know Your Weakness

8/6/12 (Monday 6th), 1:00 PM – 1:45 PM, 17 A

Matt Pollock, AE Specialist, National Instruments

 

Data communication techniques in embedded systems

8/6/12 (Monday 6th), 3:30 PM – 4:15 PM, 17 B

Vivek Nath, Systems Engineer, National Instruments

 

Rebirth of the LabVIEW state machine

8/6/12 (Monday 6th),4:30 PM – 5:15 PM,17 B

Norman Kirchner, Senior RF Systems Engineer, National Instruments

Safe travels everybody!  See you next week!