
https://www.csus.edu/indiv/v/velianitis/161/chaosreport.pdf
Also, anything that T. Capers Jones wrote. The most comprehensive one of these books is this:
Estimating Software Costs: Bringing Realism to Estimating Hardcover ISBN-13978-0071483001
Many believe the official recognition of the crisis in developing software were the two NATO conferences in 1968 and 1969.
See the Wikipedia article on the History of Software Engineering.
There have been two small scale experimental comparisons of the waterfall formal model (requirements, design, code, test) and the more prototyping and agile method. They seem to have the same productivity in terms of lines per programmer-month but the formal method tends to produce larger software.
I disagree that C is superior to C++ for most projects.
First of all, C++ offers higher-level semantics which leads to an increase in productivity. According to [1], the ratio of C++ to C LOC is 1 to 1-2.5, but I'd be interested to read other studies or articles. My experience and [1] also contradicts your statement that rewriting code with STL/Boost will lead to increased code size. It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++.
Second of all, for a developer that has good knowledge of both C and C++, writing quality C is harder. C is very prone to programmer errors, much more so than C++ where you can choose to use libraries/language features that completely eliminate some of these errors. e.g: scope-based destruction, the STL data structures, string classes, etc.
Third of all, when discussing C++ many try to make C++ look as a frightening monster ("full-blown C++"?) where you have template meta-programming interacting with automatic conversions and operator overloading and all the other features in the worst possible way. This is not much different to claiming C is bad because you can use macros and void* for everything. The languages should be compared by real-world use patterns, not dreamed up criteria.
[1] Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000)
"[...]that object-oriented programming is no panacea[...]"
While it is true that some have argued for OOP as panacea, this is mostly a strawman. OOP is one possible solution that works most of the time.