Braithwaite stresses that this is not a debate on "whether to have separate testers or whether programmers should test themselves." He simply asserts that, judging from his experience, safety is of crucial importance for software development in commercial environment. Hence, developers' ability to ensure that software does what it is expected to do should be the prerequisite to any software development job:
My point here is that it's tough to call yourself a "professional software developer" if you aren't intimately familiar with the processes by which we evaluate the result of your work.
Imagine walking up to a Structural Engineer and talking about stress-testing materials. Wouldn't you be worried if they shrugged and said, "that's testing, I just design stuff"?
Certification is not meant to impose technology choices to businesses. It is not even meant to impose any kind of standards in term of software solidity. Managers can decide to ship software full of bugs, provided they are aware of that fact.
Such approach to certification is viewed as simplistic by Peter Harkins who argues that there is more to software development then safety. Using the restaurant business analogy, Harkins stresses that he certainly doesn't want to be poisoned while eating out, but he also wants "fine food, not just fast food." Braithwaite retorts that one may dislike Mc Donald's, but this is not a reason "to legislate them out of business." Having upper standards for software is good but one should not force it on others.
For Kyle Lahnakoski, certification is meant to provide information that is otherwise missing on labour market. If focused on safety, it may result in important losses for the company if the developer turns out to be "safe" but not "efficient". Chris, however, considers safety oriented certification as a good baseline criterion for hiring employees:
On top of this - and perhaps this is obvious and thus redundant - would then come the consideration as to whether or not someone can actually write code (cook), write good code (cook well), loves writing code, works well in a team, fits with the company, and the such (cooks well enough to work in an n-star restaurant).
This goes along with Braithwaite belief that whether a developer is employable is something marketplace can decide, based on technical skills and productivity of this developer. Certification is not the only requirement for employment, exactly as Chef's papers do not guarantee getting hired by a restaurant:
Do you think a restaurant would hire anybody with their Chef's Papers? Well, some might, but some would want to know who you've worked with, some would demand that you cook them a meal. And so it is with certification. I suggest such a thing be considered necessary but not sufficient.
Safety is the prerequisite; for the rest markets will decide.