There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build.
The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)
> You can have perfectly predictable software development -- if you know exactly what it is you're going to build.
That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).
We're saying the same thing. If we haven't built it (or something very like it) before, then we cannot possibly know exactly what it is we are building, because reality has a surprising amount of detail.
The only way to increase predictability is to pad estimates to the point of meaningless, and management won't accept that. Predictability creates crunch that creates bad choices that waste time and push delivery of working product out further.
The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)