Embedded Software 101

Posted by Stephen Martin on Feb 11, 2015 8:00:00 AM


I thought I'd share some of what I have learned about development from the past 15 years. You likely have your own list. Feel free to share in the comment section. We can compare notes.

  1. Software will always have defects
  2. Code footprints inevitably grow over time
  3. The larger the code base, the greater number of potential defects
  4. The complexity of the application has a direct relationship to the number of bugs
  5. Spaghetti code is almost always the result of an unplanned development project
  6. The more independently developed software modules, the greater the likelihood of unintended consequences
  7. The further a project progresses, the more costly it is to find and fix defects and bugs
  8. There is nothing better than finding the right tool for the job – and when all else fails, use a bigger hammer!






Good tools are the way
to survive and prosper


I have also learned that software developers evolve and adapt their own techniques and work style. Here is what I’ve learned from the best of them. If you are just starting out, then take note. This could save you a lot of frustration. If you’ve been developing code for years, it’s never too late to adopt better coding practices.

  1. Plan well. Don’t start the next project without having a clear set of requirements and a plan of attack. Consider using a requirements management/tracing tool such as Visure.
  2. Keep track of your code. Set up a code repository/version control tool like Subversion or GitHub.
  3. Catch problems early. Use code analysis tools to identify potential language or structural problems. MISRA-C checkers can compare your code to proven standards and give you tips on how to rewrite. Code complexity analysis tools use an algorithm to measure the relative complexity of your C functions; keep ‘em simple and maintainable, people!
  4. Implement peer code review. Fresh eyes will see problems the original coder did not; it is a good check on the quality of the commenting and the ability to maintain the code if the reviewer can understand and follow the code. A good peer review tool can help you organize the process so you can track who is reviewing what, tag the severity of the problems found, and assign fixes.
  5. Don’t forget to keep checking what you are coding against the requirements. See step 1.
  6. Use the best debugger you can. When you get to the debug stage, the quality of your debugging environment will be critical to avoiding frustration and project delays.


Good software development benefits from planning, organizing, measuring and analyzing. Good tools like the Atollic TrueSTUDIO IDE can integrate all of this into a single development environment. Once you have used a powerful integrated tool, it is hard to go back.

Check out Atollic TrueSTUDIO Pro here

Let me know your thoughts about this list. Do you have more to add? Make a comment below.


Topics: Software quality, Debugging, Embedded Software Development