Software development: Cost vs. value

Stefan Skarin, ceo of IAR Systems, said developers appreciate ease of use, stability and reliability. "We give our customers a quick start through thousands of example projects, step by step tutorials and worldwide technical support so they can achieve fast and mature development results. Customers can measure their benefits, for example, by time – completing projects ahead of schedule and before their competitors – or by reducing hardware costs." Magnus Unemyr, vp sales and marketing with Atollic, noted: "We also provide a lot of information about using the tools: for example, white papers and video tutorials. Most customers will also download a free 30 day evaluation version of Atollic TrueSTUDIO prior to purchase." John Carbone, vp of marketing with Express Logic, took a different view. "In the end, customers and prospective customers must make their own determination regarding the expected benefits. We strongly encourage them to start with a careful and thorough look at our source code and a full evaluation license (free) that lets them see how easy it is to use our software and how well it works for them." Many tools are regarded as 'expensive' and companies can seek cheaper alternatives. Is that a false economy? How can development teams work out a return on the investment (RoI) in software? Carbone said there are two steps in such an analysis: the role of 'schedule completion' in the RoI for the product; and the role of ThreadX (an Express Logic product) versus other RTOSs. "With those two factors understood, the RoI benefit will be apparent. Embedded market forecasters perform such analyses each year, based on data they collect from developers. Such insight would be useful as a basis for individual customer analysis for their actual project." Unemyr contended that project teams need to be better at evaluating the options and not just taking the solution from previous projects. "In its simplest form," he said, "this could be checking the debugger has powerful fault analysis tools or the IDE includes software engineering features. A better basis for the decision is to perform a proper tool evaluation and to test run different tools, checking how differentiated features can save time and cost in the project at hand." Skarin believes talking about 'expensive' tools is tricky. "It is likely that free or cheap tools will turn out to cost more than an investment in IAR Embedded Workbench, for example. You lose time for training and may fail because you lack the right technology." If they're looking to perform an RoI analysis, which factors need to be included? And which are overlooked, but shouldn't be? In Unemyr's opinion: "Engineering managers need to become better in understanding that tool cost is not the major issue; rather, it's how a tool can affect the overall development time (and thus cost). The engineering manager should not accept claims like 'we can download free tools from the internet' without evidence this is the most cost effective solution, providing reasonable risk mitigation throughout the full project. According to Carbone, many factors go into a product's ROI and they often vary by company. "One variable that is often overlooked is time to market. Even a slight shortening of the development schedule can have a very beneficial effect here and on the product's success. What's interesting is that, in all cases, tool cost is dwarfed by the cost of the overall project and the difference between a successful product and one that fails to achieve its potential due to a late introduction to market." "Time is money," said Skarin. "When you waste time learning a complicated tool, on searching for matching tools to have a seamless development workflow, or on working your way out of a project cul de sac without technical support, you might end up with a delayed product and lose your competitive edge." One way in which the industry is looking to save costs is through the use of open source tools. Are these the panacea they appear to be? Are there hidden costs and unwanted surprises associated with their use? Skarin views open source tools as an important part of the embedded community. "They may spark new ideas." But when it comes to developing commercial products, he said open source is not an option. "Developers will want to achieve substantial and sustainable results and must protect their and their customers' IP. When developing safety relevant products, they will definitely need certified tools, which you will never find as open source." Carbone said: "Open source software has tremendous value for embedded development, but it is often inappropriate for product development, where liability might exist. "Open source software might contain IP that has been included improperly and, without strong indemnification against the damages of such use, it carries a risk. The risk is much smaller, if not eliminated, in 'development tools'. But an open source RTOS gets embedded into the final product and that's where rights come into play." In Unemyr's view, open source is making major inroads into the industry and, in many cases, becoming an 'industry standard'. "But projects should not be religious about open source; sometimes, they are a better match, sometimes not. Projects should evaluate each tool on its own merits and choose open source or commercial solutions as appropriate for the specific task at hand. In reality, a mixture of open source and proprietary solutions may well be the best solution in many projects." So is the industry fixated on cost, rather than value? If so, how can the balance be changed? "Keeping an eye on costs is vital," said Skarin, "so calculating current and long term costs is compulsory. Nevertheless, you need to take into account the value your embedded development team creates and what its development successes mean to your company. Human capital needs to become part of every embedded company's balance sheet." Unemyr believes price is irrelevant, unless the time/cost savings or other values are factored in. "An expensive tool is not necessarily better, while free tools may not be cost effective. A tool that only saves a little bit of engineering time usually pays for itself over and over again." Carbone concluded: "Cost is a factor, but value far outweighs cost for most product development projects. Cost should only be considered to the extent that apples are being compared to apples. When two products are compared – both might be compilers – they might be very different in performance, ease of use or reliability. This is really no different to shopping for a 'car'."