A study performed in 2008 by the NCBI found that standard advice encouraging flossing for the prevention of cavities and gum disease is not supported by scientific evidence. This conclusion wasn't drawn because scientists discovered that flossing was not a worth while preventative measure, but rather because scientists found that people were doing it incorrectly. Additionally, a study done in 2013 by the ADA reported that 50% of Americans do not floss daily in the first place. When done correctly flossing can help prevent cavities and gum disease; yet 50% of us choose not to do it at all and the majority of the rest end up doing it incorrectly.

This post is intended to be the first of a series of posts targeted at exploring some of the development challenges I have faced during my time as a test engineer primarily leveraging the NI toolchain to do my work.  I hope the series will serve as an informative and insightful look at the discipline of test engineering, it's challenges and how I have muddled through solving some of those challenges (or at least worked within their constraints).  My experience as a (fairly) recent grad and new to the discipline is that it can be hard to navigate due to it's relatively tribal nature in most organizations.  Combine that with the seemingly small number of formal educational programs in test engineering and you end up with a line of work that seems to mean many different things to many different people and organizations.  My own goal for these posts is to attempt to make some sense of it all.

I should mention that most of me experience has been spent on the software side of things, although I am no stranger to sticking my head inside a 19" rack to go looking for the source of a short.  Please provide feedback and insight (and corrections) in the comments! ​

In my last post I talked about how software has both a primary and secondary value, and how this idea relates to complexity within the framework of Scrum.  I want to take a deeper dive into the ideas of complexity and simplicity in order to establish a common vocabulary that I can use in future posts (and hopefully to spur on a discussion with you, from which we will all gain a better understanding).

If you were paying close attention as you went through the blog post on the root loop you may have noticed a little slight of hand.  I may have been stung, but I'm not sure.

In the central coastline deserts of Chile there exists an elusive wingless wasp that looks like a panda bear, is referred to as an ant, and has a sting strong enough to put a cow down.
Meet the Panda Ant:

Similarly, deep within LabVIEW there exists an elusive message loop that has the potential to sting you.  The Panda Ant is neither good (its sting can paralyze a cow) nor bad (it looks like a panda bear), but learning about it now will prevent you from getting stung by it in the future.  The same can be said for the root loop, it's not a bug in LabVIEW and you have most likely never noticed that it exists, but learning about it now could prevent you from getting stung by it in the future.

Say what you mean and mean what you say. As I delve deeper into the world of LabVIEW abstraction and SOLID code development, it becomes increasingly clear that language makes a big difference. We LabVIEW developers might recall some LVOOP primer where the presenter whipped out the old automobile class hierarchy example to convey the idea of inheritance (I'm guilty). It's an example simple enough to build a consensus of nods and let everyone leave the room clearly understanding that a car is indeed an automobile. In spite of its complete irrelevance to the code we write on a daily basis, I think there are a couple of reasons this is actually a useful example.