Page Summary
On this page we discuss why we built JADE and provide a brief history of JADE in the context of motivating factors. This page endeavors to provide general perspective on “the JADE way” in contrast to traditional software development approaches. It’s a bit of a reader, but for those so inclined we hope it sheds some light on how JADE can help you quickly build robust measurement & automation applications.
Quick Note of Appreciation - Thank You!
Before we continue, we want to thank you for learning about JADE. We understand and appreciate that there are a flood of options all claiming to be the best solution for you, and you’re spending some of your precious time here with us. We’ll do our best to communicate the JADE way with both benefits and tradeoffs, whether that means you choose JADE for your next application or not.
Why JADE?
We built JADE because there was simply no way to quickly & robustly deliver full-featured test, measurement, control, and automation applications. The pitfalls of traditional software development approaches are frustrating and costly, not only for developers but also for customers. We developers have been reinventing the proverbial wheel with the same kinds of APIs and patterns since “forever”. This resultis in lots of debugging, missing features, often clunky interfaces, sometimes missed deadlines, and many other problems. With that in mind, we can capture this problem with the following question:
Are there better building blocks with which to compose such applications?
The answer: Yes. In fact, this is “the JADE way”.
The Pitfalls of Traditional Software Development
Let’s further motivate the need for JADE. In the test, measurement, and automation world, traditional software development approaches take weeks for small applications, months for medium-sized applications, and years for large applications. And yet, all of those applications have the same core needs (ex. data acquisition & logging) and their implementations inevitably reinvent many wheels, over and over again. How often have we laid down the same design patterns & architectures, the same data acquisition & instrument control functions, the same logging & data storage code, and the same visualizations such as charts, graphs, and tables? That’s a rhetorical question of course - we all did it, essentially all of the time. In the end, perhaps 80%-90% of the code written in this space is essentially the same - just the repeated, slightly permuted use of the same APIs and patterns. And valuable time is wasted while redundantly laying it all down and debugging the same old problems.
And it gets worse. When custom software is delivered using such traditional approaches, it’s usually rigid, feature-scarce, and effectively unmaintainable. Even if the code “isn’t that bad”, it is rarely (if ever) touched again and good luck keeping the original developer(s) around for support, or passing the code on to others. It gets even worse. Documentation is going to be minimal and errant, if it exists at all. Interfaces are often clunky as the time and budget alloted was spent developing the few features that actually made it into the deliverable. And to top it off, customers typically pay a premium for such applications.
Even for a talented team, it’s just painful and limiting to lay down all of the required irreducible code when starting with relatively low-level tooling. Fortunately there is a better way.
The JADE Way (with a bit of history)
We’ve been developing applications here at Sixclear for nearly 20 years, and in that time we’ve effectively covered the space of test, measurement, and automation applications. And like other companies in the space, we carried the weight of reinventing the wheels on every project, delivering systems under time pressure, and generally feeling like there was so much more that could have been done despite all of the time and effort committed. It’s not as if we had no good tools at all - we have certainly taken advantage of - and developed - many useful libraries and abstractions. But “another, better API” doesn’t really move the needle for delivering complete, full-featured automation applications. All of the problems mentioned above remained.
Then a couple of years ago we had a bit of a eureka moment: it wasn’t that the core principles underlying the traditional approaches were wrong, it was that we simply didn’t have a way to wield the power of those principles efficiently and effectively. We were essentially building entire cities from bricks when what we needed were configurable bulidings that could easily be laid out into city blocks. In slightly more technical terms, we needed a platform (not libraries or templates) for building applications which gave us an asynchronous architecture with a communication fabric, and the ability to orchestrate independent, highly-configurable, communicating components. If done well, the 80-90% of application code which really is “the same” for all applications could be delivered by simply configuring components, while the platform & communication fabric would help avoid the need to write all of the glue code to bind the application together. Furthermore, we’d then pick up all of the features of those components everytime we used them - all without writing code.
And with that, JADE was born. JADE is now being used all over the world in applications ranging from flying around the ocean to running laboratories and production tests. With that in mind, let’s point out that “JADE” refers to the platform, and we call the components noted above “plugins” to emphasize the ease with which they can be composed and configured.
As a final note here, we would be remiss if we didn’t mention that you can - of course - develop custom plugins in JADE, which will run alongside all of the plugins we we provide. Many applications don’t need custom plugins because the generalized components we provide cover a wide range of application needs. But when you encounter a nuanced part of your application which truly requires unique effort, you can easily plug it in, just like we do when we write plugins.