I have been coding software for various computers since 1973. The one thing that I am firmly convinced of is that there is no magic bullet in terms of language, library, or methodology that is going to solve all our problems.
So why do I keep running into people who believe that this mythical -- to my mind! -- magic bullet actually exists?
I purchased multiple copies of Frederick P. Brooks' The Mythical Man Month 2nd edition — the one with the essay "No Silver Bullet" in it — to toss at over-optimistic
werewolvesmanagers who howledwandered in my direction during my 31+-year career.
The ultimate solution by management was to reduce the apparent investment in applications programming by forcibly shrinking the centralized IT budget and firing most of the expert programmers.
The coding was still done. Only it was done under the table by amateurs — and "amateurs" in the worst sense of the word.
Oh, well. I've got a decent pension out of it.
It's just human nature. Once a human has seen something work at least once and not yet seen it fail, they have to be much smarter than the average human not to assume that it will work every time.
Unfortunately, it's been my experience that the same type of people who don't document or test their code also believe in magic bullets. I don't know whether these people are lazy or just inexperienced.
Signs of that tend to be statements such as, "this code is self-documenting", "I'll test the code as I write it!", or my personal favorite, "I'll run this profiler and optimize all of my code!".
BTW, I didn't know you were also a programmer. We have to chat at the next Dorsai Thing. :-)
There have been significant improvements in programming methods over the years. Block-structured languages. Structured coding. Modularization. Interpreted languages. Objects. RDBMS. Client-server. The unified method. Extreme programming. IDEs. Each has been the magic bullet of their generation, and each has brought some actual improvements to the landscape. (IMHO objects are especially oversold, but that could be an over-exposure to o-o bigots the last few years.) And each solution, when applied to the appropriate problem space, shows real benefits. The key word is, of course, 'appropriate.'
In the real world, some of these actually work. In fact, most of them actually work. But none addresses the entire problem space, in spite of the claims of their proponents.
There's also a second effect. When there have been real improvements in software development, the field rushes ahead and addresses more and more complex problems until the improvements in productivity have been eaten up by the increased complexity of the problems addressed.
And it's understnading the complexity of the problems that is the biggest bottleneck. I can't recall how many different times I've been asked to do a 'little' job of automating a given task - only to find out the task was signficantly more complex than anyone understood.
I'm good at automating system administration. Really, really, good. But that's because I've been doing system administration for almost 30 years, and am a decent programmer to boot. Not a great programmer, merely an adequate programmer. But I understand the problem space really really well. That means my solutions actually work. It also means that sometimes I step back and say "that can't be automated." Or it can't be automated in the way that someone thinks it can, or to the degree that they desire.
A tool is just a tool. The hard part is using it.
This evolution in complexity is the reason that programming has gone from something I loved and considered myself really good at in the 1980s to something I do because I have no other marketable skills and don't like very much today. Twenty years ago I had to deal with problems that I could understand, and the time it took me to understand the problem and craft a good solution was well within what people expected. Today, to be a good programmer you need to be able to dive into a million line code base, understand how to locate other people's solutions to something like the problem at hand in the code base (found in huge code libraries and on the web), and shoehorn those solutions into the code base in far less time than it takes me to even find and start to understand the third party solutions, much less how to glue them in without rewriting either the third party solution or the code base. I'm damn good at writing new code to solve problems; I'm lousy (or at least a lot less good) at adapting someone else's solution to almost my problem without rewriting it.