Tools – 5 Justifications for Purchasing a New Software Tool

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 $1200 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 $1500. 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 one-hundred and thirty 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. (Let’s not forget other benefits such as improved robust, possible decreases in time to market and similar results).

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 fifteen 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 $1200 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.

Justification #5 – Code size reduction

Flash space has become inexpensive on many modern day microcontrollers but the ability to save between twenty and sixty 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 $1200 so if a developer can optimize code to squeeze into a smaller flash size, the break-even point for the tool purchase is 6000 units assuming $0.20 savings or 2000 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 ten 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.

Share >

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.