People are generaly optimists and with that anything in the future will be biased towards ideals, even planning for exceptions will bias towards a ideal.
The other factor is feature creep, if you find a project so well defined and set in stone then it would be fair to say it will have a better chance of finishing on time.
That is just the software side, then there is the hardware to run it and that opens up a whole new aspect of poetntual delays that will get leveridged at the project and when people say project behind involving software people will just focus on the software aspect and all other factors are buried.
Bugs and issues come from many factors and even suppliers of hardware can have bugs which can have a impact, design could have bugs and many aspects can have issues that impact the end result.
But it is impossible and silly to plan for every situation as whatever you plan for there will be an exception and you get a deminishing return, hence easier to have a area of time labeled contingency as a catch all. Best example of such exceptions would be say an earthquake killing your entire development team, that can and has happened and at the same time is not something you plan for. Partialy why we have insurance. Though you will find it very hard to impossible to get insurace again software development delays beyond life/death of parties involved, though that will not chance the delay into a non-delay, mearly compensate.
With all this Engineers have for many lifetimes gone with the engineering factor or whatever you think it will take, muliply that by 2-3 to counter optimisim. But that does not help feture creep and anything added to the design after code has started is creep.
The other factor is feature creep, if you find a project so well defined and set in stone then it would be fair to say it will have a better chance of finishing on time.
That is just the software side, then there is the hardware to run it and that opens up a whole new aspect of poetntual delays that will get leveridged at the project and when people say project behind involving software people will just focus on the software aspect and all other factors are buried.
Bugs and issues come from many factors and even suppliers of hardware can have bugs which can have a impact, design could have bugs and many aspects can have issues that impact the end result.
But it is impossible and silly to plan for every situation as whatever you plan for there will be an exception and you get a deminishing return, hence easier to have a area of time labeled contingency as a catch all. Best example of such exceptions would be say an earthquake killing your entire development team, that can and has happened and at the same time is not something you plan for. Partialy why we have insurance. Though you will find it very hard to impossible to get insurace again software development delays beyond life/death of parties involved, though that will not chance the delay into a non-delay, mearly compensate.
With all this Engineers have for many lifetimes gone with the engineering factor or whatever you think it will take, muliply that by 2-3 to counter optimisim. But that does not help feture creep and anything added to the design after code has started is creep.