The start of a new year, especially one that is the start of a new decade, provides a great excuse to carefully evaluate and review how you develop embedded systems and put in place a plan to improve it. The techniques and processes that are used to effectively develop products are constantly changing and improving, but when a team is in the middle of development, it’s easy to stick with what you know out of fear of being slowed down. The truth though is that modernizing your techniques can accelerate development, improve quality and allow a team to get more done in the same amount of time. In today’s post, we are going to examine five tips for improving embedded development that I know many teams across the planet could use in the new year.

Tip #1 – Start Measuring Key Metrics and Drivers

It is nearly impossible to make any effective changes to the way that you develop an embedded system if you are not measuring key metrics and drivers about how you build systems. Just like with a business, developers need to:

• measure key metrics and drivers
• Review and identify inefficiencies, problem areas, etc
• Identify and implement actions for improvement
• Repeat the process 

In order to make the process work, you may need to figure out what metrics you should be measuring. These could be things like:

• time spent developing a component
• Time spent debugging
• Defects
• Lines of code per week
• Test cases per week

Or whatever metric makes sense for your team. 

What do you do if your team is not on-board with tracking metrics? You can create and measure your own personal software development process. When I was an entry-level engineer working at one of my first embedded software jobs, I identified metrics that were important to me and then measured them. That led me early on to discover that I spent way too much time debugging which led me to research and develop techniques that decreased debugging time or prevented it. (I literally went from 80% of my time back then to maybe 10% now). 

Tip #2 – Start having Code Reviews

Code reviews are one of the most effective ways at minimizing defects in an embedded system, code reviews are one of the activities that developers drag their feet on doing the most. I’m not sure if it’s because developers are too concerned with bruising their own egos or if they are afraid that they will look like they don’t know what they are doing in front of their colleagues or if there is some other reason. The truth is there is no such thing as a perfect programmer and not only can code reviews efficiently discover defects, it’s also a great way to learn more embedded skills and get constructive feedback from your teammates. 

Tip #3 – Master Debugging Skills

My personal preference would be to master skills that prevent defects in a system, but no matter how good a developer or team may be, defects will happen. It’s critical that teams master defect prevention techniques and also debugging techniques. Embedded systems surveys show that the average developers spends 40% of their time debugging, which equates to nearly 5 months in a given year! The lowest hanging fruit for any development team to improve their development cycle is to prevent bugs and master the techniques necessary to quickly find the ones that do make it through. Decreasing debugging time from 40% to 30% can save 6 weeks of development time per developer which can add up not just in development time but cost, quality and features. 

Tip #4 – Start Automating Testing

Manually testing software is a slow, boring and error prone process. Any software additional or modification may result in having to go back and retest the entire system to ensure that the change did not break anything. Even a simple system can require lots of testing. Modern software development processes integrate automated testing and continuous integration servers in order to perform regression testing and other software analysis. While these processes can be time consuming to setup, in the larger scheme, they provide a way to improve code quality and decrease the time and labor that is spent testing.   

Advocates for test driven development can point to all kinds of interesting statistics about how important it is to first design your test case and then write the code that makes that test pass successfully. I’ve never fully adopted TDD personally, but I’ve found that adopting many of its tenants have helped improve my own software, such as automating test cases and thinking about the test case first.  

Tip #5 – Separate Software Concerns

I’m a big advocate for developing software that is modular and reusable. I’ve developed dozens of products so far in my career and I quickly discovered that while different industries can deliver very different products, there are core features and design patterns that contribute to the products customer facing features. Modularizing and reusing these features can allow developers to focus on the value added features and reuse the others instead of reinventing the wheel. 

Portability and reuse all start with separating software concerns within the code base, or perhaps importantly, in the software architecture. Existing code bases are often tightly coupled or may have low cohesion as multiple features are all implemented in the same software modules. Developing new modules that are highly cohesive and have low coupling will improve code reuse and portability and also make it easier for developers to maintain and scale the code. 

Conclusions

There is never a best time to start improving the way that you design and build embedded systems. Waiting for the perfect time will simply result in the same old day to day fires, long nights and working weekends. Don’t wait for the perfect time to measure and improve your development processes, that time will never come. The five tips we’ve discussed in todays post are low hanging fruit that can be easily implemented and contribute to a feedback loop that will allow development to become more efficient, cost effective and more consistent.