But it is important to realize that this has nothing to do with time passing. The most expensive failed software project ever was the attempt to the modernize the FAA, in the USA, from 1982 to 1994, a project which cost $3.7 billion and which failed completely. And there, too, the problem was too many tools, too much abstraction, too many experiments with options:
"The project was handed over to human factor pundits, who then drove the design. Requirements became synonymous with preferences. Thousands of labor-months were spent designing, discussing, and demonstrating the possibilities: colors, fonts, overlays, reversals, serpentine lists, toggling, zooming, opaque windows, the list is huge. It was something to see. (Virtually all of the marketing brochures – produced prematurely and in large numbers – sparkled with some rendition or other of the new controller console.) It just wasn’t usable… The cost of what turned out to be a 14-year human factors study did not pay off. Shortly before the project was terminated a controller on the CBS evening news said: “It takes me 12 commands to do what I used to do with one.” I believe he spoke for everyone with common sense."
So we would be wrong to think that software developers were productive in the past, whereas now they are not productive. But rather, some paradigms of development tend towards too much abstraction, and when followed they lead to failed projects. That was true in the 1980s, and it is true now.
I do think, on the frontend, the desire to take markup languages such as HTML, and then make them work on all output devices (desktop computers, tablets, mobile phones) has lead to an era where too much abstraction is the norm on frontend projects. I tried to imagine an alternative in my essay "The problem with HTML":