I am sure most calibration technicians and lab managers have never heard of Low-Code and No-Code software development. To be honest, before a year ago neither had I, but now I think this is going to be a game changer—even bigger than Object Oriented Programming (OOP) was in the 80s and 90s. If you have read anything from me, it’s easy to conclude I am a huge OOP advocate.
So let me first explain the concept of Low-Code/No-Code by explaining what it is not. The overarching idea is to create working software without the overhead of thousands upon thousands of lines of code a developer has to write and support. Software is expensive to write and maintain. And those of use in the business know, poorly written code is extremely expensive to support and maintain. That is the idea behind this software movement: do more with less.
The concept of Low-Code/No-Code comes in several flavors. The first is the idea of domain-specific languages that allow users to build their own software, usually with a graphical development environment. Generally, these tools will allow a user to define items and flow of the software in a flow-chart like format. Then the software will write the actual code from the flow-chart. One example we all know that fits this pattern is LabView. And for those who have used LabView, it really makes complex instrumentation control easy.
Another idea behind Low-Code to No-Code is the idea of skipping the visual development environment. Here, the idea is to take the data items and convert them directly to computer instructions based on standard processes. The best example of this is database access code. Create, Read, Update and Delete (CRUD) access to a database is pretty much standard across all databases.
But wait, there’s more! CRUD access, because it is standardized, can be implemented across any database and the software can auto-generate the SQL scripts on the fly. So now the developer doesn’t need to write SQL access scripts, since they are done automatically. And small changes from one database to another are also managed in the auto-generated scripts.
This type of database/application programming has become the standard. Programmers today will write applications based on an Object-Relational Model where all the SQL code will be written for them automatically. And if they want to support a no-SQL database, all they have to do is change the database connector. Everything is handled for them, with No-Code!
This brings us back to a year ago when I first learned about Low-Code/No-Code from Mahdi, a friend of mine working on his Ph.D. developing a Low-Code solution in the Netherlands. As he was explaining to me the concepts behind the Low-Code he was working on I started thinking that’s what Metrology.NET® does. Then he said “Exactly! That is what I am trying to tell you.” Mahdi was one of the developers on the team that developed version 1.0 of Metrology.NET and neither of us realized it was a Low-Code solution.
Now, looking back on the goals of the project, it is easy to see just how much Low-Code technologies and concepts we managed to build into the software. Our goal was to approach metrology from a purely Object-Oriented perspective, defining all of the instrument settings and measurement process variables into name-value pairs. These name-value pairs could then be used to set up and configure the hardware during the measurement process.
When I designed the architecture of Metrology.NET, I wanted to get more use out of the code that I wrote. I wanted to put my data into a single silo that was reusable. I also wanted to create data points and automation in Metrology.NET. But if a customer wanted a MET/CAL® procedure I could press a button and get 80% of the code automatically generated from the Metrology.NET Test Package.
I know as I explain this to other programmers, it takes a little bit of time to wrap your head around Low-Code to No-Code software development. But if you think about it like this, the name-value pairs are timeless. They will always be the same for a given UUT and metrology taxon. The actual test script is just a way of expressing the name-value pairs in greater detail. And if software can write software with a press of a button, we can output name-value pairs into any language you can imagine. That is the end goal of No-Code software development.
