This March we’ll hold the fifth annual LabVIEW Certified LabVIEW Architect Summit in Austin. The CLA Summit was pretty much Nancy’s idea. It owes its existence to Nancy’s stubborn tenacious nature to make things happen. She believed that if you put a bunch of the best LabVIEW programmers in the world into one room, valuable discussion would ensue, and she was clearly right about that. I also remember her signing me up to host the first CLA Summit dinner at my house, and then telling me what I’d volunteered for.

The Summit keeps growing. (It’s too big for dinner at my house—sorry!) We’ve expanded to Europe. A couple of weeks after the Austin CLA Summit, we’ll hold the third annual European CLA Summit in Geneva, Switzerland, at CERN.

The dates are March 3-5, 2014, in Austin, and March 18-20, in Geneva. You can read more about it here (ni.com/cla-summit). Signup links will be available on that page soon.

Share this:

Like this:

I’m pleased to share that the Lawrence Livermore National Laboratory (LLNL) is our sixth and newest LabVIEW Center of Excellence. Here’s a photo of Mike Flegel accepting the award from Dr. T, and another photo with the NI and LLNL teams.

The LabVIEW Center of Excellence program recognizes organizations that have a high level of both individual and organizational proficiency. Technical leaders are required to be Certified LabVIEW Architects, and the organizations must have good software engineering practices and training plans.

Like this:

In the last six months I have conducted LabVIEW proficiency surveys with well over 100 programmers. One of the last questions that I ask is “What else do you need to be more successful on your projects?” What do think the number one response is? Time. Everyone needs more time. And this is one of the primary benefits of integrating the TSVN Toolkit from Viewpoint Systems into your workflow. This valuable third-party toolkit is currently available at www.ni.com/toolsnetwork.

In this post I hope to save you a little more time by introducing you to the toolkit, answering some common questions, and referencing useful links from the community for those who are new to source code control (SCC).

Did I mention that this valuable toolkit is free (and the game-plan moving forward is for it to continue to be free)!

Share this:

Like this:

Thank you for reading this five-part series on being a humble programmer. (Links to parts one, two, three, four, and five.)

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.

Share this:

Like this:

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.

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.

Share this:

Like this:

As I discussed in part 3, getting feedback on code you wrote is an excellent way to learn to be a better programmer. Everybody needs to set aside their egos and look at code reviews as a learning opportunity…

Share this:

Like this:

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.

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…

Share this:

Like this:

In part 1, I talked about how I grew up in a coding culture that emphasized community. While not the only way, I prefer this approach. It takes some humility. Your code is out there for others to read, debug, explain, and modify—and in the end, laud or complain about.

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.

Share this:

Like this:

Paris, France – We’re in the midst of the 2013 European CLA Summit. We have over 50 CLAs meeting for two and a half days, discussing advanced LabVIEW concepts. This year’s theme is Interprocess Communications. We’ve had presentations by several CLAs from around the world. (Including a few CLAs who traveled from the USA to attend.)

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.

About

The National Instruments Field Architects are a small, elite group of LabVIEW experts. We help your engineers become more proficient in LabVIEW. We guide software architectures, develop technical leaders, and teach and encourage good software engineering.

The views expressed in this blog are ours alone and do not necessarily reflect the views of National Instruments Corporation.