Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

3 Ways to Improve Your Software Development Environment

Adobe Stock AdobeStock_169328354_1540-800.jpeg
Software teams should take time to improve their development environment.

Developers should find the time to take stock of their software development environment and where it could be improved. I often find that development teams spend most of their time scrambling to meet deadlines and crank out product features. Also, I’ve found that across industries and companies, there are always improvements that could be made. Below is my list of the top three improvement areas that embedded software developers should consider.

Improvement #1 – Leverage a unit test harness

Whether we like it or not, testing embedded software is critical 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 forward to the point where even the smallest embedded software teams can benefit from using the tools. 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 interact with existing code.

I’ve personally seen significant benefits in my software development using test harnesses and following a more test-driven development (TDD) type of development process. If you or your team are not using a test harness, you really should.

Improvement #2 – Spend less time debugging

I know that there are many embedded software engineers who love the challenge of debugging software. To them, it’s challenging and rewarding. 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 do.

According to any number of surveys, and conference talks, the average developer spends about 40 percent of their time debugging. That amount of time equates to nearly 4.8 work months per year spent debugging! Decreasing that number by 10 percent from 40 percent to 30 percent would save 1.2 work months per developer per year! Recovering debug time can benefit by reducing project costs, helping teams deliver on time, reduce stress, and a myriad of other benefits.

Improvement #3 – Review and improve your processes

Typically, I encounter two types of teams. 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 to have a balanced approach that allows for repeatability but maintains the development team’s flexibility and adaptability.

Developers should find the time to think through what processes exist and whether they need to be modified. Are processes still in place from 10 or 15 years ago that are being followed blindly and may 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 strategies to ensure that critical 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 a necessary evil and should be periodically adjusted to meet the changing needs of the company.  

Conclusions

Developers tend to store up baggage on how we build systems. Sometimes, this baggage results in good best practices, while other times, they are knee-jerk reactions from getting burned on a project. In today’s post, we’ve examined several common improvements that developers can incorporate into their software development environment. 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?

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees, including a Master of Engineering from the University of Michigan. Feel free to contact him at jacob@beningo.com at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.

Hide comments
account-default-image

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish