[elihu]

I wonder if people don't take the wrong lesson from this essay. There might not be any single 10x productivity-enhancing technology, but there have been many modest improvements. I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995.

Someone reading this today might be tempted to dismiss tools they just don't understand as "not a silver bullet". However, even modest improvements are worth striving for, and if you only adopt what is "industry standard", you'll always be behind your early-adopter peers. (Or at least, those of your early-adopter peers who have good enough taste to distinguish a good, useful technology from the next shiny new thing that isn't ready for production and may never be.)

Things that have been a boon to me have been getting into Linux back in the early days when it was new-ish, the arrival of Google, learning Haskell, learning to use source control (first svn, now git), and the availability of things like Stack Overflow and Wikipedia. If I had to go back to using the tools of the mid nineties (Borland Turbo C++ on Windows 3.1, NCSA Mosaic and a 14.4kbps modem, 33mhz processors, 8 megs of ram, etc...), I could still sort of get stuff done as a programmer but really we've come a long long way since then.

[pvg]

It sounds like you personally gained access to better tools and that programming tools and productivity enhancing technology in general have become far more accessible. But programmers had access to unix workstations, dvcs, places to ask and answer questions online, etc, in 1995 as well. "It's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995" is an extraordinary claim without any of the required extraordinary evidence.

[bhntr3]

So, this paper is actually from 1986. More fuel for your argument.

Out of the Tar Pit (http://shaffner.us/cs/papers/tarpit.pdf) is an interesting response. I'm not convinced Functional Relational Programming is a silver bullet. But I think the arguments about state are certainly compelling.

After reading Out of the Tar Pit, I got the impression that No Silver Bullet was perhaps accurate for individual programmers. But I think there are still lots of silver bullets for teams of programmers. I think a lot of your examples fall in that category. Source control, internet resources, etc. That all helps us collaborate.

I think maybe Out of the Tar Pit points at some things we can do in our code to improve our productivity as a group (by making code easier to understand and reason about.) I think some of Bret Victor's immediate feedback stuff (https://vimeo.com/36579366) and the places the Eve team are taking it (http://www.chris-granger.com/2015/08/17/version-0/) are also pointing in that direction.

Ultimately, I think a lot of the crappiness in software these days exists because the things that are very easy for a single programmer make things hard for a group. It's funny because the author of "No Silver Bullet" is also the author of "The Mythical Man Month". Maybe he doesn't focus on collaboration because the conclusion of the Mythical Man Month was "only let one person code and have everyone else support him."

[narag]

" I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995."

I don't know about fairness, but definitively that's wrong. I was around then and the most I could believe is that we are 2x.

[elihu]

I think it depends on what you're doing, and what counts as productivity. I think lines of code per developer per day haven't gone up much, but it's a lot easier to deliver much more complex products now than it was then, in part due to the large volume of readily accessible library code. There's less need to write special-purpose code for everything, because someone probably wrote the generic parts already.

There are some software domains that haven't changed much at all since the 90s or earlier. Systems programming is still done largely in C and C++, and modern kernels work basically the same way they did then with a few minor differences. Scripting has changed dramatically, web frameworks have changed dramatically, business applications have changed quite a bit. C# is noticeably different from Java, which is different from C++ or Cobol or whatever it was people used to write business software in back then.

[nickbauman]

The biggest problems in tech are not technological but the social interaction of primary creative agents: those of us responsible for making great strides in magnifying human intellect. Those of us making the software.

[kpil]

The biggest problems that we could be better at, at least.

One other hard problem is to figure out how to construct systems that are not so damn fragile. I am not talking about raid-5 here, but how to find ways to tackle the intrinsic complexity of our problems so that minor faults in our definitions and solutions will not cause catastrophically nonlinear crashes.

Maybe that requires hard AI, but it would be nice if when developing the equivalent of a house, the boiler would not explode and destroy the house if one forgot to connect the doorbell. If you see what I mean.

Back to the original topic: No I don't think an average developer is 10x more productive now, maybe 2x thanks to that it's so much easier to find information about everything, but the intrinsic complexity is still there, and we still have the same brains.

Although I think that google and wikipedia are an enabler - For my hobby projects I can google and implement a really quick/smart algorithm that I probably would not find - less invent myself. However; It does not help the typical "enterprise" coder that is churning out boring code while trying to figure out ill-defined and complex rules.

I believe though that the developer variance is 10x - at least when regarding long term maintainability. (Less time wasted on fixing old bugs, easier to implement new features, etc, etc.) Unfortunately, only a few people are required to complicate things beyond repair so the larger the team, the less does it matter.

I just got reminded of my favourite observation:

Complicated problems requires complicated solutions. It follows that if someone is a bit dense, all their problems are complicated. Therefore, the solutions will too be complicated.

[nickbauman]

Or just Conway's Law. One of the things that Cloud Computing is imposing (with its inherently stochastic performance variation) is the notion that developers develop systems that are inherently fault tolerant. It's been a long time since I wrote programs that trusted other components to always do their job.