[cowanon22]

"No Silver Bullet" is similar to "Moore's law" - an observation rather than an absolute rule. In both cases, the authors were only projecting into the future 10 years.

It is just measurement, not pessimism or optimism. The fact that "No Silver Bullet" is still true 35 years later show just how hard progress can be.

[Nevermark]

Fred Brooks wasn't just making an observation.

He was making a case that there was no room for such significant jumps in software efficiency because most software development was now focused on essential complexity, not accidental complexity.

http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

That argument does not hold water to me for two reasons:

1. I think a lot of programming, from glue code to optimization to bug fixing, is still accidental complexity.

2. The level of reuse is still nowhere near reflective of the fact that the majority of code is recoding of already well known algorithms, patterns, and methods with only slightly differences for the current problem context. This happens for business, technical and social reasons.

So I see huge potential for progress. Whether that progress will ever involve a 10x improvement due to a single major insight I don't know. But there is room for it to happen.

[goto11]

Sure there is huge potential for progress, but Brooks have not argued otherwise. He just states there will not be a single invention which will increase productivity 10x across the board.

Just as an example, a lot of developer time is spent trying to understand some legacy code in order to apply a fix. No single programming technique or tool will make that go away.

[Nevermark]

Well he argues that, but his argument is incomplete. I have identified a single reason for massive amounts of inefficiency: the difficulty of reusing code in slightly different contexts and conditions requiring massive amounts of similar code being created by innumerable programmers.

No doubt there are many small problems that solved one by one would product incremental improvements.

But there is at lease the POTENTIAL for a 10x improvement if code reuse in the presence of varying conditions was made more practical, given the radical savings massive reuse would enable.

Another single massive problem is glue code between code bases dealing with similar or relatable functionality, but using very different API's or data formats. Again, maybe that can only be addressed with numerous small incremental advances.

Glue code being a common cross-industry problem, there is at least a possibility that a widely applicable glue code generating system would replace huge amounts of manually written glue code, creating a 10x increase in productivity by both eliminating the work of writing lots of glue code, and allowing different code bases to be used together that were not economically feasible to combine before.

I am not arguing that a 10x advance is inevitable. That would make my arguments as weak as the arguments that a 10x advance is impossible. I am just point out there are large widespread inefficiencies today that could make a 10x improvement possible.

The argument that there are no single massive inefficiencies left to solve, only many small inefficiencies, because most coding is now dealing with inherent complexity instead of accidental complexity falls on its face. Both the difficulty of reuse and the difficulty of integration are huge problems of accidental complexity.