Mastering the 8 Pillars of Embedded Software

8 Pillars of Embedded Software
Modified Original (c) Joe Ravi CC-BY-SA 3.0

Every embedded software program starts with a basic foundation from which the application is built. A successful application requires that the developer build the application using knowledge of the eight pillars of embedded software which include:

  • Architecture
  • Code Analysis
  • Debugging
  • Documentation
  • Language Skills
  • Standards
  • Testing
  • Tools / Ecosystem

Skill deficiencies in any of these pillars can result in firmware that is buggy, not easily maintained and doesn’t meet industry standards among many other non-ideal results such as increased costs and delayed product launch dates.

In order to ensure that developers are up to the challenge, there are three steps that need to followed to master these eight pillars of embedded software.

  1. Evaluate today the developers comfort level in each of these key areas
  2. Determine the pillar to focus on that will result in the greatest value and impact
  3. Determine the steps necessary to move the comfort level with that pillar to the next level

In step one, the easiest way to evaluate how a developer stands in each of these areas is to create a spider chart with each of the pillars on an axis. Using a rating system from 1 to 10, the developer ranks whether they consider themselves to be entry level (1) or master (10) of that particular pillar. The result is a diagram that would look something similar to Figure 1. From a quick glance,

8PillarsEvaluation

Figure 1 – Beningo’s 8 Pillar Evaluation

it is easy to determine where a developers’ strengths and weaknesses are located at. In the above example, it is obvious that the developer is very strong in developing documentation but not the greatest at industry standards.

The second step is to determine which of these pillars should have the primary focus for improvement over the next several months. Many managers would look for the weakest pillar and focus there but that isn’t necessarily going to provide the greatest value or impact. Perhaps the engineer is weakest in testing but never does any testing. Focusing on testing would increase knowledge for the developer but probably not impact the day-to-day development environment. On the other hand, maybe focusing on software architecture, already a strength for the developer, would result in drastic improvements to the code base or schedule. Don’t jump to conclusions!

The final step, once the pillar has been selected, is to identify what it will take to increase the mastery of that pillar by a one or two. For every developer or team, it will be different. For some, simply reading a few papers might do the trick. For others, maybe a hands-on course or more time on the job to experiment in the area of improvement. Identify a couple courses of actions and a deadline to have those actions completed. At the end of the period, a developer can then reevaluate themselves to determine where the next improvement should come.

Don’t forget that improvements are incremental and won’t happen overnight. A half hour each day can quickly result in huge gains in skills which have the end result of decreasing company costs and time to market.

Next steps:

  1. Draw out the “Beningos’ 8 Pillars of Embedded Software” evaluation spider chart and evaluate your own skill level
  2. Identify a pillar you want to focus on over the course of the next several months
  3. Determine what actions you’ll take to improve and the deadline
  4. Start mastering the pillars

Working in a corporate environment that wants to dramatically decrease costs and time to market? Contact Jacob today to learn how he can help you formally evaluate and develop a strategy to strengthen your teams’ pillars to improve performance, decrease bug rates and drastically improve embedded software development.

Leave a Reply

Your email address will not be published. Required fields are marked *