Let’s face it, every embedded software developer knows that management is more likely to approve the purchase for a $50,000 spectrum analyzer than a $1,200 debug probe with ETM trace capabilities. Purchasing a compiler, trace software, analyzers or any other tool that would make software development easier, faster, or cheaper simply results in management asking why an open source tool can’t be used or whether a developer can get by for now without. Here are five justifications developers can use with management to push that desperately needed tool through the approval process.

Justification #1 -- Development Speed Increases

For any project, the most expensive budget consumer is undoubtedly engineering time. Productive and knowledgeable engineers with their loaded salary (including benefits, vacations, etc.) can easily top $150,000 per year. As a rule of thumb, the break-even point to purchase a tool that improves development speed by 1% is $1,500. A greater increase in development speed or a lower cost per percent is a no brainer purchase. Stop the debate and just buy the tool.

Justification #2 -- Decreased Bug Rate

Software bugs can be extremely expensive and need to be taken seriously. Just look at the payout for Toyota’s unintended acceleration bug (greater than $1 billion) and it becomes obvious that a single bug could potentially break a company. A good software analysis tool can cost anywhere from $400 to $10,000. A company with a good metrics tracking program could easily calculate the average cost per bug and the bug number per project. The result could then be used to calculate the bug number that is required to reach a break-even point.

An alternative calculation is to estimate how many hours are spent debugging per year and then determine if the analysis tool can decrease that amount by at least the equivalent dollar amount. For example, purchasing a $400 analysis tool would need to decrease debug time by a little over five hours per year assuming the fully loaded hourly rate for an engineer is $75. The more expensive $10,000 tools would need to decrease debug time by approximately 130 hours. Spread those hours across a few team members and suddenly even that expensive tool looks like it will save the company money in the mid to long term.

Firmware for Embedded Systems. Jacob Beningo will be leading sessions on HAL design for MCUs, real-time software using Micro Python, and how to create an IoT device in 45 minutes — all happening at the Embedded Systems Conference, Sept. 21-22, 2016 in Minneapolis. Register here for the event, hosted by Design News’ parent company, UBM.

Justification #3 -- Efficient Bug Removal

The later in the development cycle a bug is discovered, the costlier it is to fix. Obviously a bug discovered during the requirements phase only needs to have a document updated, which takes maybe 15 minutes. Discovering a bug during testing though, that could take days or maybe even weeks to track down. A bug that takes an entire day to resolve costs at least $600 in just engineering time let alone any losses due to market share and schedule slippage. A debugger with advanced trace capabilities is typically $1,200 with the software being equivalent. Saving a single week in debugging suddenly justifies the cost for both tools. To truly understand the return on investment, a developer should use their own teams bug rates and debugging times to get an accurate result.

Justification #4 -- Decreases Time to Market

Having the right tools available during the development cycle can result in getting a product to market sooner rather than later. Being first to market and gaining market share can sometimes be the difference between success and failure. While it can be difficult to quantify how much time may be decreased in a development cycle (if any) or launching a product early might have, any tool that can decrease time to market shouldn’t be taken lightly. Examining the variables at play and finding a way to calculate the break-even point is a great way to justify a tool purchase to management.

READ MORE HOW-TO ARTICLES ON DESIGN NEWS:

Justification #5 -- Code Size Reduction

Flash space has become inexpensive on many modern day microcontrollers but the ability to save between 20 and 60 cents per unit especially in a high volume application can add up fast! Using a commercial compiler or purchasing optimization tools could result in production cost savings. Optimization plug-ins cost around $1,200 so if a developer can optimize code to squeeze into a smaller flash size, the break-even point for the tool purchase is 6,000 units assuming $0.20 savings or 2,000 units assuming $0.60 savings.

Conclusions

In every justification, we examined the break-even point assuming the tool is used for a single project. Embedded software tools are rarely used as one-offs and usually have a useful life from five to 10 years that cover potentially a dozen or more projects. The long term savings between labor and manufacturing costs can easily equate to tens of thousands of dollars. Despite the large potential savings, embedded software tools are commonly put on the back burner and developers struggle through development, burning through precious time and capital. It’s time to start justifying why a tool shouldn’t be purchased rather than the reverse.

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 which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com, and sign up for his monthly Embedded Bytes Newsletter here.