The case for using a standard framework

Why should I use a standard framework instead of my homebrew QSM, producer-consumer, etc architecture?

I spent May 21-24 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 have 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 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 got 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 2 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 homebrew framework may be really awesome, but chances are you haven’t invested the time to develop the tooling necessary to make you really efficient. The AF, DQMH, and DCAF all include tons of tooling to speed you up.

All 3 frameworks are also geared around reuse. They all 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 foci this year at NI week was software test. In fact, there was a mini-track devoted to it.  All 3 of these frameworks have been tested (2 of them directly by NI and the other by one of the biggest advocates for unit testing in the community).  In addition, all 3 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. However, chances are it wasn’t very well documented and probably did some stuff that made it very difficult to understand. 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 and 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 just completely scrap it and start from scratch because they can’t figure it out.

With a standard framework, if the developer disappears, there are enough other developers out there using these frameworks, that 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 them?
2. Does your framework encourage reuse? Can you easily drag modules along 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?

Curious which Framework is right for you?

Click the button below to see the presentation I created for NI Days that talks about how to evaluate which frameworks are right for you. It talks extensively about 2 of the more popular frameworks: The Actor Framework and the Delacor Queued Message Handler.