Recently, I’ve been launching a little office project to develop a new training curriculum for DISTek engineers. Because it is hands-on training, it will require a toolchain. Since our customers use everything from off-the-shelf professional solutions to home-brewed ones, it’s important to prevent the nuances of a new toolchain from being a distraction in the training’s purpose of conveying good software practices and controls concepts.
I recently graduated from Iowa State University and began my career at DISTek, and during that time there is one thing that I notice engineers hate doing: documentation. Despite being loathed, it's widely believed documentation is one of the most important things in software development. I always strive to see that code my teams and I have worked on will be well documented in some form or another. I, especially, run into problems with code that is developed as a library (a set of functions and data structures).
If you’re a regular reader of this blog, then you probably know a lot of about the areas that DISTek works within. Our expertise ranges across the off-highway vehicle industry (including agriculture, construction, and forestry) with engineers that specialize in a variety of disciplines. Out of convenience, we typically group these disciplines into three big areas (“embedded software”, “automation and test”, and “modeling and simulation”), but the reality is that we do all kinds of projects that cross-over between these disciplines.
Another year has come and gone and many eventful happenings took place in the history of DISTek. We may look back at 2015 as a turning point due to the substantial changes we made in all aspects of our business. Those end-of-the-year cards you get in the mail always seem to be bragging a little too much, but that is just what I am going to do because I think the year DISTek had is worth bragging about.
While reading David Allen’s Getting Things Done, I connected the ideas that Allen suggests for time allocation to that of a real-time operating system with which I am familiar. Upon further thought, I wondered if there is a way to act more deterministic and accomplish tasks at higher efficiency, similar to how a microprocessor performs within a real-time operating system.
While I was attending the Embedded Systems Conference this year in San Jose, there was one session that peaked my interest. The session was “Design Patterns for Embedded Systems in C” from Bruce Powel Douglass, Ph.D., Chief Evangelist from IBM IoT(Internet of Things).
In college, I had a physics class called Modeling and Simulation of Physics Systems in which students wrote code to model the physical behavior of various systems. The final project of the class involved choosing a system of interest, developing a model for it, and presenting the results with some sensatory aid.