A Standard individual: New year, new opportunities

2/24/2010 10:15 AM EST

As a new columnist to embedded.com, I was looking around some of the other columns. It seems that many of the same questions are asked on both sides of the Atlantic. Certification of tools and engineers, outsourcing, standards: both ISO and de-facto, piracy, copyright, patents and licensing of tools and software. I covered some of these issues in previous columns.

One thing I have noticed of late, probably due to the recession to some extent, is people looking for "free" tools and software. Now this may cheer the Open Source fraternity, but it is not what it seems. What people are looking for is something for free not only do they not want to pay any money, but neither do they want to bother with any license restrictions or obligations, feeding bug fixes back and helping the community, etc., let alone making their source code available.

Whilst some commercial tools and software are being pirated, so are the Open Source equivalents, but in a slightly different way. The problem is that whilst one is clearly illegal as it usually involves hacking or hacked software and passwords or license keys of dubious origin, Open Source piracy is less obviously as the source code is "free" and who reads the licence files with software anyway? The FSF is taking steps to reverse this for Open Source, but it's a drop in the ocean.

Another factor is that silicon companies are releasing more free software to generate microprocessor sales. This includes peripheral libraries, USB, TCP/IP, file systems, and all manner of example projects that contain far more code than ever before. They also put pressure on compiler companies and distributors to make the commercial tools available at a discount. I saw a comment from a couple of engineers that "if the silicon companies want me to use their chips, the tools should be provided free of charge." Try suggesting to a software distributor that they give you free MCUs to help make a compiler/software sale.

The perceived value of software is dropping and this increases the subconscious idea that it should be free. This is not good for programmers and it won't help Open Source as the programmers will be expected to build and maintain the tools on their own time and not spend company time feeding back bug reports and going on-line to help the community. This is already happening. One company I know "re-organised" out some of its staff that were their Open Source gurus, as it was felt they were spending too much time helping others outside the company and "playing" rather than developing. They still use the Open Source tools, but staff is encouraged to chat with the community (support & maintenance) on their own time.

Think back to the "good old days" in other trades when you were expected to make your own tools on your own time and expense before starting a job.

I have started to see a bit more of the short-term accountancy coming in as well. People look at the cost to buy an item not the "total cost of ownership." This has come up several times recently.

In one case, there were two development suites. One was a quarter the cost of the other. However, it became apparent some months into the project that the cheaper tool was less efficient in its code generation by a large margin. The code required additional memory chips. This costs not only the memory chips, but design time, added cost to the PCB manufacture—holes cost money—and more power required and more heat generated. On a build of 10,000 units per year, they were already into costs of five or six times the initial saving.

Then it came to test and debug; debugging with the cheaper tool is far less capable and harder to use than the more expensive one. There have now been weeks of project slippage and more in view. The cost in this part of the project alone has been about five man-weeks or the cost of two more of the more of expensive compilers, never mind the slippage on the deadlines.

In addition, the debug system in the cheaper compiler is less capable. Hence, it's not so easy to use, and the testing was not as comprehensive and the system is less reliable.

The saving of 1500 GBP at the start of the project will cost them around 10,000 GBP per year of production. It's more difficult to calculate the cost of a late and/or unreliable product. Ask Toyota what the damage is or ask Microsoft what Vista did to its bottom line. A late and unreliable product can change the profile of a company and give a competitor an advantage it may never loose. Read "In Search of Stupidity" to see how disastrous it can get.

The trouble I have found is that most engineers are as clueless about project control, resources, time lines, and presenting cost analysis as accountants are about software. Embedded engineers must be able to quantify things and present the financial arguments.