"Let's see how this essential complexity claim holds for a couple of things I did recently at work:" "For some queries, it's arguably zero — my work was necess

"Let's see how this essential complexity claim holds for a couple of things I did recently at work:" "For some queries, it's arguably zero — my work was necessary only because of some arbitrary quirk and there would be no work to do without the quirk. But even in cases where some kind of query seems necessary, I think it's unbelievable that essential complexity could have been more than 1% of the complexity I had to deal with." It's very clear that the author of the post understands "essential complexity" as related to thinking about the query they need to write (data structures). The issue is that in today's computing environments application programming is only a fraction of solving the problem of delivering the application. They too see the essential (or inherent) complexity as being a domain and requirements related thing, but they draw the conclusion that they are somehow not part of it. It is possible the whole app and system would be unnecessary if the essential complexity was addressed differently. And it is also possible that due to the current way of doing things, there are new sources of essential (inherent) complexity. Brooks couldn't have foreseen productivity gains coming from the internet and collaboration. But if you factor all that in and create a new baseline, faster machines still don't tell you what is the best way to deal with changes in requirements or how to represent a postal address so that it works internationally.