"Diversity" and "inclusiveness" isn't about adding more randomness to a selection, it's about introducing an explicit and deliberate bias. Special outreach programs favor candidates with lower _distribution_ in the available populace. Not only is it discrimination by itself, against the current majority, but it's self-defeating measure, in that every diversity hire skews the remaining pool of candidates more towards the biased majority it's trying to eliminate. This is usually combined with a concerted effort to ignore the actual sources of skew in the first place, because the implications go against ideas of blank-slatism and politically correct thought.

If you want to bring moral imperatives into it, one would think a basic commitment to truth and statistical literacy would be included, but it very rarely is. You'd also imagine diversity of thought would be included as a point of intellectual honesty, but in practice, it is the exact opposite.

As for software projects routinely failing, that has numerous possible explanations. One is that it's one of the most abstract forms of engineering around, in the sense that the material we manipulate and the arrangements we construct cannot be seen or touched, and hence are invisible to outsiders. It must rely entirely on explicit and deliberate communication, unlike more practical fields. The onus is entirely on the engineer to make himself understandable, and it is rare to find people gifted both in abstraction and verbal thinking.

Another is the recurring observation that schools are particularly bad at teaching the practical skills required to deliver software projects, being taught by people with little to no industry experience. It goes beyond basic project and code management skills and goes into product design and usability: people learn to build code when they should be learning to craft tools. But just because currently applications focus more on theory than practice, doesn't mean we'd get better results by turning to people who lack the theory entirely.