Our previous blog highlighted key hardware considerations when selecting a new enterprise embedded platform for your company. This blog will dive into the key software considerations. The software will consist …
When it comes to determining a new enterprise embedded platform to control the functionality of an off-highway vehicle, there are many considerations that need to be contemplated. This blog article, …
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.
In a world of complex systems, it may be easy to forget some of the basic concepts that build these systems. Software applications can consist of hundreds of individual files as part of one very large project. Those files all work together to achieve amazing functionality within an embedded system. There are instances where a project may include files written by teams located in different countries. We like to think that when this software is put into production all the bugs have been discovered and the software will work perfectly. Unfortunately, there always seems to be unintended use or a sequence of events that result in undesired functionality. Other times, there is just a plain old bug that managed to find its way into production software.
Commenting code is one topic, that until recently, I hadn’t known was such a widely debated issue in the programming world. It was something taught to me from day one in Computer Science at the University of Northern Iowa. Recently, my workplace posted a simple question on an open-discussion white board. “Should we comment our code?” The plethora of anonymous comments was certainly enough to pique my interest. According to the discussion, hardly anyone could agree on this question.
“I enjoy doing code reviews!” said no embedded software development engineer, ever.
Nobody in their right mind takes pleasure in combing through hundreds of lines of Consolas 9.5 gibberish they didn’t even add, modify, or remove. There are no rewards. No incentives. Only an engineer at the other end of the diff-viewer who thinks you’re just trying to get under his skin, thinks you’re a know-it-all, or assumes your stylistic preferences are a personal criticism.
Okay, that may be a bit aggressive, but nonetheless, can be very true.
