So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured ou

So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured out the essence of certain classes of problems and others learned to apply their experience. But, isn't that the case with any domain built on knowledge? My point was that a skilled developer had learned much the state of the art knowledge up to this point, and understands the pitfalls over over-complicating a solution that one can get into with certain solutions of the problem. Brooks' paper wasn't even getting deeply into what we are talking about, he was just suggesting that software development is inherently complicated, that it's always going to be hard, because unlike Newtonian physics, you can't wave away the complexities and distill the essence of a problem into simple equations. The complexities ARE the software. Abstractions, though helpful, are flawed and leaky, unless they're designed by a master. If software development is a fundamentally hard activity, like playing a musical instrument well, you're not likely going to make it a "breakthrough" with a piece of technology, you're going to improve it with better programmers. A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. Back in the 80's, this was bitter medicine that management types had to hear, thinking that programming was rote activity with barely any need for higher pay or recognition of the 10:1 or more disparity in productivity among individuals.