The case for using a standard framework

195 VIEWS

Why Should I Use a Standard Framework Instead of My Homebrew QSM, Producer-Consumer Architecture?

I spent May 21st-24th in Austin for NI Week  (see my review here). If you have been following any of my recent posts and presentations, you will know that I have done a lot of presentations lately on the Actor Framework (AF) and the Delacor Queued Message Handler (DQMH). After NI week, I added the Distributed Control and Automation Framework (DCAF) to my list of favorite frameworks. I haven’t used it yet for a project, but I saw a bunch of presentations, and it looks very promising. I’ve kind of become a student of various frameworks lately.

Being a student of frameworks, I naturally asked as many participants as I could at NI week: “Which framework are you using?” I got a variety of responses. It was not very scientific, but the most popular framework was probably the AF, followed very closely by the DQMH. Surprisingly, though, the most common answer I received was: “I don’t need a framework. I have my own homebrew QSM or producer-consumer architecture.”

NOTE: I am not using the term “homebrew” in a derogatory sense, but merely to indicate that whatever framework you’ve created is not published and readily available to the public.

If you saw my presentation on Choosing a Framework, you might remember the following two slides:

I talked about reasons to use a framework and why you may not want to roll your own. I am not saying that your Homebrew architecture is a horrible choice. I am also not saying that DQMH, AF or DCAF will solve all your problems.  There are times when they may not be the right solution. But in what follows I am going to try to make a case for why you may want to try and standardize on one of these frameworks for the projects where they make sense, instead of trying to use your homebrewed architecture.

 

The Case for Using a Standard Framework

1. Speed up your development time

I firmly believe that using any one of the standard frameworks I’ve mentioned so far will make your development go much faster. In that respect, the biggest advantage you get from using a standard framework is the tooling. Your homebrewed framework may be really awesome, but chances are you haven’t invested the time to develop the tooling necessary to be really efficient. The AF, DQMH, and DCAF all include tons of tooling to speed you up.

All three frameworks are also geared around reuse. They each have several reusable modules already available for common tasks. AF has Network Endpoint Actors and State Pattern Actors built-in that ship with LabVIEW. If you look through Fab’s blog for DQMH, you will find a variety of modules that you can use out of the box. DCAF has lots of modules available for things like PID, Modbus, and Scan Engine.

2. Write better code

One of the big focuses this year at NI week was software testing. In fact, there was a mini-track devoted to it.  All three of these frameworks have been tested (two of them directly by NI and the other by one of the biggest advocates for unit testing in the community). In addition, all three make it easy to do interactive or unit-testing of your modules. In the DQMH, it is even built in.  For the AF, we at SAS have a tool to help out.  I haven’t seen any tools specific to DCAF, but from the presentation I saw, unit-testing should be very easy, since the whole system uses the tag bus as an abstraction layer.

3. Don’t leave your customer out to dry

Most of us have inherited projects where some other developer used their own homebrew architecture. Maybe you got lucky and it was pretty simple and easy to understand. But chances are it wasn’t very well documented and probably did some stuff that made it very difficult to  comprehend. Think of how the customer feels in that situation. They paid for software thinking it would be easy to add upgrades in the future. The developer disappears, so they go hire another. The new developer either tells them it’s going to be difficult to add the features they want, or tells them to completely scrap what they have and start over from scratch because he/she can’t figure it out.

With a standard framework, if the developer disappears, there are enough other developers out there using that framework that the customer should be able to easily find one. These standard frameworks are well-documented and supported.

Questions to Ask Yourself

If you still insist on using your own framework, that is fine.  However, I highly recommend you consider the following questions:

  1. Does your framework provide the tooling necessary to make you truly efficient? If not, do you have the skill, time, and energy to create and maintain it?
  2. Does your framework encourage reuse? Can you easily drag modules from one project to another?
  3. Have you unit-tested your framework? Does your framework encourage easy unit-testing of your modules?
  4. What would happen to your customers if you disappeared? What is the learning curve on your framework? How well is it documented?

Sam makes it easier for LabVIEW Teams to write great code. Sam helps them develop and implement processes that take advantage of the latest software engineering tools so everything flows smoothly and the developers can focus on what they do best, solving their customer's problem.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu