Question of the Week: Do you use formal selection criteria when choosing software languages and programming tools?

Apple’s recent change to section 3.3.1 of the iPhone Developer Program License Agreement for the 4.0 SDK explicitly limits developers to using

“…Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs application”

While this limitation applies to application code, my own project experience for embedded control systems suggests that other development teams also impose analogous selection criteria on language and development tool choices. In some cases, our choices were limited to a short approved list of languages and development tool environments that applied across many suppliers that were contributing different subsystems to a single, long-lived end-system.

Understanding what criteria developers use to limit language and tool selection is more than an academic concern. In countless presentations I have seen software development tools rank at or near the top in importance in selecting a processor as the final candidate for designs. Suggested reasons why development tools manifest so highly in processor choices include familiarity with the toolset and its specific quirks to avoid a new learning curve and preserve an aggressive design schedule.

Technical reasons for specific selections might include execution efficiency of the compiled code, compilation speed, code size efficiency of the generated executable, as well as the tool’s flexibility to spot-optimize all of these considerations. The tool’s static and dynamic analysis capabilities, as well as traceability and testing components may also be important considerations.

I suspect that the selection criteria across all embedded design teams vary widely and are reliant on the target applications, size and maturity of the development team, and expected maintenance lifecycle of the end product. For example, if an end-product has a 10, 20, or even 30 year maintenance lifecycle (such as an automobile, aircraft, or spacecraft), then it is imperative to choose a language and set of tools that have high chance of being supported throughout that lifecycle period. Another important consideration for such long lived products is whether there will continue to be a sufficient pool of skilled engineers with working experience in the selected language into the future.

With this in mind, I am hoping to uncover common sets of reasoning for formal language and tool selection criteria across the range of embedded development projects. Understanding that, please share any formal selection criteria you use and for what type of applications do you use them for?

To make following the Question of the Week series easier (especially with multiple overlapping series), I am including the index below to previous relevant posts. I will be summarizing your answers for these questions in a paper at the end of the series. I encourage you to check out all of the posts for the question of the week series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned here. I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to suggest a question, please contact me.

2010, April 7: Is robotics engineering different enough from embedded engineering to warrant being treated as a separate discipline?

2010, March 31: When does it make sense to use an RTOS or operating system?

2010, March 24: Question of the Week: Do you use or allow dynamic memory allocation in your embedded design?

2010, March 17: Question of the Week: You know you’re an embedded developer when …