The start of a new year is the perfect time to take a few moments and examine what worked and what did not work last year. I often find that development teams spend most of their time scrambling to meet deadlines and crank out product features. In general, I’ve found that across industries and dramatically different size companies, there are still several new year resolutions that would benefit most teams. Below is my list of top three resolutions for embedded software developers as they kick-off 2021.
Resolution #1 – Leverage a unit test harness
Whether we like it or not, testing embedded software is a critical piece to every product development cycle. I’ve found that in general, embedded software developers spot check their software but typically don’t have a test harness in place to assist in automated regression testing. (Obviously this varies from one organization to the next and may even depend on the type of product being developed).
Over the last several years, software development process tools have made huge leaps and bounds to the point where even the smallest embedded software teams can benefit. Test harnesses and even continuous integration are no exception. Test harnesses provide developers with the ability to perform automated regression testing to ensure that the code is working as expected and that no new additions are interacting with existing code.
I’ve personally seen major benefits in my own software development to using test harnesses and following a more test-driven development (TDD) type of development processes. If you or your team are not using a test harness, leveraging test harnesses might be a good resolution for you this year.
Resolution #2 – Spend less time debugging
I know that there are many embedded software engineers out there who love the challenge of debugging software. To them it’s challenging and rewarding, and it makes them tick. For me, I find debugging to be the bane of an embedded software developer’s existence! Given the complexity of today’s embedded systems, debugging is necessary, but the time spent debugging should be minimized as much as possible. Debugging is by nature, failure work. Code is written that should work, but it doesn’t so developers then spent considerable time rewriting and rewriting until it does what it is supposed to (at least as far as they can tell).
There are plenty of surveys out there and I’ve also verified through my own newsletter subscribers and while giving talks at conferences that the average developer spends about 40% of their time debugging. That equates to nearly 4.8 work months per year spent debugging! Decreasing that number by 10% from 40% to 30% would save 1.2 work months per developer per year! Recovering debug time can have the benefit of decreasing project costs, helping teams deliver on-time, decrease stress along with a myriad of other benefits.
If you find that you or your team spend a considerable amount of time debugging, this is the year to learn how to avoid it and learn the right skills to minimize the time spent debugging when it has to be done.
Resolution #3 – Review and improve your processes
This very well may be the most controversial resolution that one can make this year. I say this because I encounter two types of teams typically. The first has too little process which impedes their ability to provide consistent, quality results. The second has too much process which decreases their speed and flexibility and can make it nearly impossible to get anything done. The key to sustained success is always to have a balanced approach that allows for repeatability but maintains flexibility and adaptability of the development team.
In the new year, take some time to think through what processes exist and whether or not they need to be modified. Are processes still in place from 10 or 15 years ago that are being followed blindly that maybe no longer apply? Could they be streamlined to improve speed while still maintaining their original intent? Perhaps there is too little process. Where might it make sense to add some processes in place to ensure that key steps in development are not overlooked? What areas consistently come up short and cause recurring headaches, schedule delays and loss of productivity?
As much as we might want to label processes as evil, they are in fact a necessary evil and should be periodically tuned to meet the needs of the company.
The new year is a fantastic time to reflect on what has worked in the past and what has not worked and to chart a new course. From year to year, we often tend to store up baggage on how we build systems. Sometimes that baggage results in good best practices that are followed while other times they are knee jerk reactions to getting burned on a project. In today’s post, we’ve examined several common resolutions that developers can make to improve their software development environment this year. I’ve focused on the three key areas that I often see as issues with companies: testing, debugging and process management.
What specific things would you like to change this year to improve how you develop software?