My 2015 LabVIEW Resolution
It’s a new year which means we must assume everything we did before last week was rubbish and change everything.
OK, that’s a slightly cynical view but it does always amaze me how quickly advertising, blogs and news changes at this time of year. That’s also not to say that I haven’t joined in, as I ease back into work I have enjoyed looking back at 2014 as a year of great change (starting Wiresmith Technology) and now look forward to improving in 2015.
Quality means doing it right when no one is looking – Henry Ford
One big focus point for me is going to be software quality. As old projects finish and new ones start, I want to make sure I have done everything in my power to prevent old projects coming back with issues. Some problems are inevitable but it costs time to fix and lost time on other projects to have to refocus.
I find it interesting that when it comes to software bugs are considered inevitable, even as I started by business and got contracts drawn up, the templates all include clauses stating this. Whilst there is an element of truth (software is a complex system) I also think it can lead to a relaxed attitude towards defects that you wouldn’t find in other fields.
Software never was perfect and won’t get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality – Boris Beizer
When it comes to quality I think the first step has to be testing. I have been using the unit test framework from NI on a couple of projects now as well as unit test frameworks in javascript and I am convinced it is the way forward. By the end of the year I want to be doing something akin to TDD.
The key reason is simple, when I have been writing tests as I have written code (not always strictly first, but as I am initially developing) I have found bugs. Therefore, there is only two possible outcomes to me not testing:
- I discover that bug as I test the integration of that code into the main product. This could take a lot of time if it is not clear what subVI is the source of the bug and I have to go back and fix it. Even knowing the subVI it means I have to get back into the same mentality as when I wrote it, which also takes time.
- I still miss it and the customer finds it instead. This is more costly to debug as you are likely going to find it harder to debug from the customers descriptions down to a subVI, never mind knocking the customers confidence in you.
To do this requires two things, the right mentality and the right tools.
For the mentality, discipline is the biggest requirement to begin with. I know the process and it will feel unnatural at first but I hope to push through the initial pain to get to the rolling green pastures on the other side.
For the tools, there are really two in existence for LabVIEW. The Unit Test Framework (UTF) from NI and JKI’s VI Tester. I have tried UTF quite a bit and want to return and evaluate VI Tester over the next couple of months to understand its advantages.
For both of these, keep an eye out over the next few months when I hope to report back on my progress and findings with them. No doubt I will also be discussing this on the NI community as well. Check out the Unit Testing group over there if you want to learn more (and from more experienced people).
Fab
January 5, 2015Excellent article! I specially liked your comment
“As old projects finish and new ones start, I want to make sure I have done everything in my power to prevent old projects coming back with issues.”
I love when customers call back with new projects, new challenges, that is a lot more fun than having to go back and debug/troubleshoot/fix old code. This has driven me to always think on how I am going to test the code very early on. It also guides other approaches like creating meaningful error reporting early on the project. For example, I do leave “automatic error handling” ON early on a project. Why? Because I want LabVIEW to report on any error that I might not be handling properly. Scan from string and Format into string are some of my favorite VIs, but they are also know for being brittle when new code is being created. I want to know if I forgot to wire one of the inputs or if one of the arguments changed. When the code is mature, I am OK turning off the “automatic error handling”.
Another great benefit of making your code easy to test is that in the case where a customer does come back, you will already have the tools to isolate, troubleshoot, debug and fix the issue faster. Today a customer told me: “When I call you with a bug and it takes you less than 30 minutes to find out what the problem is, why it was caused and how to fix it, I know I am working with the right person”. This is after he had spent a couple of hours trying to figure out what was wrong on his own.
Thanks for the shout out for the “Unit Testing Group” I hope we all learn more ways of achieving a development approach that is closer to Test Development Driven (TDD) development. Also, the LabVIEW Community needs better Unit Testing tools and giving feedback about UTF and JKI VI Tester can lead to improve those tools.
Happy New Year! and my best wishes for you and your family.
Looking forward to learning more about your journey towards TDD.
Best regards,
Fab
James McNally
January 6, 2015“When I call you with a bug and it takes you less than 30 minutes to find out what the problem is, why it was caused and how to fix it, I know I am working with the right person”
That is a great comment and a really good example. When it comes to customer relations it is this downtime that can be critical to a customer and soon outweighs the cost of development.