FBW, IT, and situation awareness
A couple points about FBW systems (I do some embedded/control sytem work, not FBW, but close enough I feel able to dispel some misinformation here). Personally I don't think FBW-issues are at all likely factors in this accident though autopilot/autothrust might be (However, in non-FBW systems these would be factors too).
The idea that it takes something like a million lines of code to automate flight is based on a number of logical mistakes. I don't doubt that once one starts adding more complex elements of avoinic systems, it might approach a million lines of code, but, this is somewhat meaningless. In short folks assume that airplane avionics control software and Microsoft Windows face similar challenges because they are both "software." Actually, this is not the case. (I have done testing on some versions of Microsoft Windows, and some embedded system design, so...)
The first thing is that software engineers who are going to work on a specific problem are going to have to understand the nature of the problem well enough to have intelligent governsations with specialists as to finer points. Specifications need to be understood in context, and software engineers need to be involved in the specification process. The idea that avionics systems are designed by folks who have no general aviation knowledge is silly (and there would have been a lot more accidents if this were the case).
The second thing is that most of the avionics units are actually going to be reasonably simple matters of sensor input and data output. ADIRU's, the TCAS, VSC, etc. all fit into this category. These systems can be validated both symbolically and via automated testing in ways that general-purpose computer programs can't. A simple rule to bear in mind here is that the effort required to validate software is proportional to 2^n where n represents the compexity of input. Simple input means robust testibility. ADIRU systems for example, would have reasonably simple inputs. Also simple inputs have the advantage in that it is practical to symbolically analise source code here to determine that it WILL handle all sensor input appropriately. Some systems seem less subject to full validation (TCAS systems for example) than others (ADIRU's, for example).
However, since one system's output is usualy an input elsewhere, more restricted output improves testability of the entire system.
Controllers, such as those found in avoinics systems, are remarkably simple, testable, and even verifiable via non-testing methods in a way that general purpose computer software is not. Embedded controllers are everywhere-- in our offices, cars, homes, etc. and have been shown to be reliable. Some elements may still be beyond testability (in particular, you can't protect against sensors inputing consistently incorrect data in this way, nor can you rule out every possible timing issue, but you CAN experientially and even mathematically prove that correct inputs will be acted on correctly).
Now, I do see one POSSIBLE issue with computerized systems in the AF447 incident involving the issues of self-healing systems. Pitot icing detection works on the assumption that there are at least mild differences in severity in the icing in different tubes (hence different stagnation pressures detected). The computers typicaly vote out the outlying system and in this case, this can be dangerous because it is possible that the outlying system is more correct than the two (more consistently iced up) tubes report. In this case, autothrust might have been increased prior to autopilot disconnect and the plane might have been going substantially faster than anyone understood at the time it was handed back to the pilots.
All in all, I think it is possible that self-healing element of FBW systems played a role in this incident. However, this isn't a matter of a bug or a glitch but rather the (human) difficulty in maintaining situation awareness with a computer with which one interacts in limited ways. Such degraded situation awareness may have been a contributing factor. I don't think this means that systems shouldn't be self-healing, but rather that pilots might do well to have more transparent diagnostic information available to them (including outlying readings from instruments).