As James Robertson points out, there are reasons to favor the Software as a Craft metaphor over the Software as a Factory metaphor. But he writes "software is still a craft" (emphasis mine).
That's almost an apology. I'm not sure how intentional his words align with my interpretation, but the notion is commonly expressed, as if someday it won't be a craft but for now it is. Usually the notion is that someday software will be more like "real engineering".
I've taken another view on these metaphors. Let's forget about factories because 10 seconds of thought informs us this does not fit well at all. So the candidates seem to be "craft" or "engineering".
My view is there are things software developers can learn from various kinds of engineers. Maybe there is something to be learned from legal engineering certification processes. But the lack of doing so is not what makes software development seem craft-like.
I think the "informality" of software makes it feel craft-like. If only we had more formalisms. Could be, but we'll always have "informalities". Every engineering effort, and every creative effort in general, involves many informal conversations.
The difference is perhaps software depends more on informal conversations than do many of the traditional engineering disciplines. The requirements in those disciplines are more formal. Most of software development is really requirements development. The interpretation of formal requirements is most easily expressed in software as tests and code that (correctly one hopes) runs those tests.
I think the key difference between software development and traditional engineering disciplines is not primarily the lack of discipline. Rather it is the inherent predominance of informal conversation and that software development fails mostly due to lack of communication. There is room to improve our formalisms for sure. But those improvements will not replace the focus on informal conversation the way standards and formalisms have in traditional engineering disciplines.
Those software development improvements have to support informal conversation. That's why the agile approaches have been successful... when they have improved communication for a specific team, they have improved the results without any new technology or formalisms. Of course some of that communication is in the form of "knowledge transfer" of how to use the available formal tools better. But in the aggregate it is *all* sorts of communication among the whole team that has made agile approaches successful. And when they have not been successful, in my experience it is not from failing to use a formalism well, it is failure to communicate well.