Reliability of software scheduling

Reliability of software scheduling. Recently I've been wondering why software seems to be inheritly hard to develop and deliver. Here's my current theory. When building software you have to build upon others work. At a minimal you call routines in the Operating System. Now you have to rely on how well these routines work. Question - How many times have you as a programmer (/software engineer) used a routine that didn't work as documented? Any experienced programmer has come across this many times during any one project. So now let's imagine that you are an 'expert' at scheduling the development process. You take into account the pieces you are going to use: OS API's, 3rd Party tools, etc. Now how can you truly estimate the time it's going to take if the pieces that make up the project are so unreliable? Can you really estimate how long it's going to take to, 'work-around' problems that are in key components? Let's take the example of people whos workmenship is important. Those that build houses rely on the tools and parts they use. Would it be logical to use pieces that don't work. Logically not. These people rely on proven parts. Over and over again. The question now is why can't software developers do the samething? Why not use the same tools and parts to build software? Take proven parts and get proven results. The problem is the software field changes so often that tools and pieces are never around long enough to prove their reliability. So it seems illogical to build on these foundations. What's the solution? We need tools and platforms that we can build on for a 'long' time. What do I consider long? Minimally a decade. Why a decade? According to the definition of what is considered an, 'expert' it takes at least 10 years to be an expert. Therefore after building something with a background of 10 years of reliability one should be able to finally depend on it.