How many of you know how your car engine works well enough to fix basic issues? How many of you have a parent or kid that knows how to do these things? It wasn’t long ago at all that this was pretty common knowledge in much of the US, at least for folks with an engineering bent, even if they never worked in the auto industry. I still have a rather tremendous number of tools, jacks and stands, and even an appropriately greasy Chilton’s Repair Manual cluttering up my garage. However, the reality is that my current car is so reliable that it’s not productive for me to be prepared to fix or tweak it. To get where I’m going these days, I just need to be able to drive it.
The increases we are seeing in software development productivity are built on the same concepts, though it is sometimes gussied up in fancier words like “abstraction” and “encapsulation.” It comes down to the same simple concept: if you can count on an existing thing (be it software, hardware, a tool or even a coworker) to work reliably, you will be most productive if you simply “drive” it using the exposed controls. More importantly, if you set up the controls properly, many more people will be able to learn how to use it than will ever know how it works.
In a programming context, over the last 20 years, more and more functionality have become reliable and reusable. From compilers, to operating systems, to libraries and market-specific programming environments (such as Atego, Simulink and LabView), they continue to evolve.
How powerful are these programming environments getting? Shockingly so. I remember programming my first application in Logo. After intensive effort, I managed to get a turtle to move in a somewhat interesting pattern. A generation later, my daughter recently wrote her first program. Using Kodu she put together an Xbox video game (code-named “Water World”) complete with 3D terrain, interacting characters, keybound actions, conditional behaviors, and so on. In less than two hours. In first grade.
Think about that. In a world where computers are, quite literally, everywhere and part of everything you do, there is incredible potential in unleashing the creativity of people who think of themselves as non-programmers. One example that has recently been close to my heart is the RTI sales operations team. No one in that team has ever taken even a single programming or engineering class. They don’t know what a compiler is or does (and never will). But when I ask them to go change our SalesForce.com based Customer Management system they can create tremendous value to our sales teams and executives. They might not be traditional “software engineers” but they also aren’t end-users or admins, they are programmers working in a graphical language that is (increasingly well) designed to allow them to program in a paradigm that matches the problem-space that they are trying to solve.
Right now, the programming environments built for embedded software are still a step or two behind those available for enterprise software. Embedded systems have always needed to optimize their resource usage more tightly and abstraction typically comes at a cost of some overhead. That overhead, on a million units, used to cost too much. But with the advances in technology that allow all these devices to communicate with each other, there are revenue opportunities for companies that can more rapidly evolve their embedded products (often including already fielded devices) towards a model where multitudes of intelligence workers can develop software systems that interact with and depend on these devices just as you and I drive a car today: by depending on their functionality without the need to understand their implementation.
The leaders in the embedded world are making this happen and at RTI we have a front row seat to watch, and guide, this evolution across many different industries. Our customers are leading the charge to integrate their embedded devices into future-proof distributed-system programming frameworks with the goal of empowering an ever greater number of people to derive benefit (and drive revenue) from these once-closed systems.