2.3 Connect: Software Robustness

Hey guys. I'm Adrian.
I'm Nick.
And welcome to "Connect." So today we're bringing a subject matter expert to talk a little bit about what we're doing to ensure software robustness. On the previous episode, we talked a little bit about some of the software components we have in our SDK. And we wanted to bring Henry Wiechman here to talk a little bit about what we're doing internally to ensure customers are getting a high quality product to build their application on top of. So thanks for joining us, Henry.
My pleasure.
So I don't know if you wanted to walk through some of the things that we're doing internally to help developers trust and leverage validated software components.
Sure. I think it really starts with our software development process in general. We spend a lot of time working on requirements from the market, inputs that we get from our field sales teams and from customers directly, and just from experience that we've had working with devices and seeing issues that customers may have. So we take their requirements. And we'll put those into play in terms of the actual development of the code itself.
We will go through a series of different tests starting with component level testing and then go into a more complete system level test. We will run a lot of different industry standard test suites. We'll do different types of interoperability testing to see how the different devices in the stacks that we have play with some of the others that are out in the industry, make sure that there is good interoperability and connection.
We'll also do different types of static analysis to make sure that we don't have any dead paths in the code, things of that nature. And the key thing is we'll be doing this on a regular basis. So we'll go through multiple iterations. We do weekly builds. So there's continuous integration in the product. We'll go in and run complete test suites on those weekly builds and make adjustments as needed.
And then as we get ready for a final release, we'll add in some additional system level tests and some final interoperability and actual user experience types of tests as well. So it's a complete set. And we do that not only multiple times for each release, but then we will do each release on a quarterly basis. And that allows us then to repeat the cycle again. So we'll have a lot of lessons learned that we'll get out there and can go in and then make updates.
And the key thing for the quarterly releases is that that's a regular cadence, so customers have some predictability. They know that should an issue happen to come up, they know that there is another release coming just in the very next quarter so they can do their plans accordingly to have those updates out there on a regular basis.
And I guess a final thing I should mention as well is just the fact that we spent a lot of time with regression testing and with making sure that we don't have any incompatibilities introduced so customers know that what's working today, I'll get it next quarter. Everything that I had should work. We'll have some new features and capabilities added into that as well. So we really spend a lot of time and investment on that. It's a process that we've actually developed over many, many years of software development.
Very cool. And you mentioned interoperability testing. So with a lot of the stacks that we're integrating, whether that be Bluetooth or Wi-Fi, are there things that we're doing internally to make sure that we're working with certain access points or phones to ensure that the customer's end products don't have any potential gotchas from an interoperability perspective?
Yeah, that's a great point. In the case of Wi-Fi for example, our Wi-Fi stacks are tested with over 200 different access points. We've got all of those set up. And we do that testing on a regular basis to make sure that that interoperability is there. On the VLE side as well, we're setting up a similar level of interoperability tests with a similar number of different points.
OK.
And I qualified in our previous episode where we talked about the SimpleLink software that I'm not a software expert. And a couple of questions popped up from what you were saying. So the first one is, as a developer, if I'm a software developer, why do I care that there is a quarterly release cadence? You said we release regular updates. Can you explain the importance of that and why that would matter to me?
Yeah. That's a good question. The main thing is that predictability allows our end customers then to have more predictability in their schedules. So with software, software is always an evolutionary type of a product. Several years ago, I was hearing one of the experts industry talking about how software's never done. And while that makes a lot of managers very uncomfortable, it really is the truth, because you can continuously evolve.
You can always be tweaking things. So we have an effort on continuous improvement, but we do regular releases so customers can then plan for when the next update is coming, when there might be new issues or issues that are resolved, new features coming in a predictable basis so they can plan accordingly.
Now one question that might be related that often comes up with customers is, do I have to do this quarterly release cadence? And of course the answer is no. Certainly as the customers get close to their end release, as they get close to their production, they will freeze their code. And at that point, of course, they don't need to do any updates.
OK. The other question I had, when you mentioned the testing, you mentioned component level testing and also system level testing. Can you talk about what some of the consequences are if that testing wasn't done and what the importance is of completing that kind of testing?
Sure. Yeah. The component test is, you know with any of the different software SDKs that we have, there's multiple components. So the first thing we do when we're creating a new component is to test the component itself, just check basic functionality.
We then go through and do different types of tests in terms of integrating those components. And a lot of times companies in the past have stopped there and they just rely on just that component test and maybe some basic integration to be enough. What we found is more of the challenges come after you've done the basic integration and as you try to actually use the full set of components in an actual product.
So we try to go to as close to an end system environment as we can and check out multiple different use cases on that full set of components as part of the system test to understand how all that works together. And many times that's where you find some intricacies that you hadn't always expected. And so that system test is one that's vitally important to us, and it's one that we add to regularly. We often will add new tests as we have different customer use cases and scenarios come up to expand that and really make sure that we are getting a very robust set there for the customers to check out.
That's awesome. And with the quarterly release cadence, how can developers keep up to date with what's being introduced, what bugs are getting fixed, and also just get proactively notified as these releases happen throughout the year?
Good question. So we do actually have a process where you can sign up for updates on each release. We have what we call the AlertMe button that is on TI.com when you're on the software download page. It's a little red button there that you can click on. And basically when you do that, you're signing up for these regular alerts or updates. So as the new release comes out in the quarter, you get a short email that explains what's new, any issues that were resolved, et cetera, and then that you can use in your planning as well as a customer to figure out, OK, this is something I want to update on or no, maybe I can hold off on that.
Awesome. Well thanks, Henry. That learned a lot. I think there's a lot that we're doing to help developers leverage our validated software to build their differentiated applications on top of.
Yeah. And thanks everybody for joining this episode of "Connect." If you want to learn more about what Henry was talking about, you can visit TI.com/simplelink or ti.com/simplelinkSDK. If you have any further questions, you can tweet at me @SensorToCloud and interact with me there. Next week, join us for a demo of motor condition monitoring for predictive maintenance. It's a very cool demo. Be sure to tune in. Thanks, guys.

Details

Date:
August 22, 2018

Why does software robustness really matter? Henry Wiechman, a TI software expert will walk through the full SimpleLink™ software development process, including testing, release cadence, interoperability, and more.

The SimpleLink software development kit offers 100% code portability from one SimpleLink platform device to another so that the development team won’t have to start over with new code or make massive revisions to the code base. In addition, team members won’t have to learn new tools to incorporate the small amount of new application code needed for new features.