You wouldn't be the first by a long shot to try to figure out the best way to plan development time. This is in part due to the fact that it is difficult to quantify something you cannot actually see being built, and partly due to the mythical man-month, which is a direct contrast to the intuitive idea that if you have 2 programmers, you should be able to develop twice as fast than if you had 1 programmer.
As you've probably realized already, it is a lot more complicated than that. One approach to estimating development time as rounding a group of highly qualified individuals for what concerns software development and ask them to estimate the amount of time it would take to finish a project (explaining as detailed as possible). You take the highest of all the estimates and you double it. Yes, you read correctly. You double the highest estimate and you shall have a reasonably accurate estimate. I know, because with time, this is how I've been able to accurately tell my bosses how long it takes me to do something. I gather the opinions of my fellow programmers and my own and double the highest estimate. If this seems like too high of a value, consider that testing new functionality is crucial and consider potential bug fixes afterwards, and it will seem like a more reasonable figure.
In my own personal experience as a programmer, I can tell you that it helps to break down projects into milestones. How long does it take to reach milestone 1, then from milestone 1 to milestone 2, then milestone 2 to milestone 3, etc.? When broken down like this, the answer is usually far more accurate than trying to estimate the entire project in its entirety. Strangely enough, if you sum up the estimates of all these milestones, it will usually be larger than the original estimate on the entire project (if the programmer is being honest with himself anyway), which only leads me to think that detail is the key here.
Perhaps you lack the technical know-how, but you should still try to follow on a more general level. Programmers have no problems with repetition. It's the twists and turns that occupy all the time in developing a program. So most likely, the more functionality that you wish to include, the more complicated the program is going to become, and assuming this new functionality has no influence on previously implemented sections of the code, development will be linear according to the amount of work to be done. Most likely, new functionality heavily influences previously implemented sections and thus development involves not just implementing the new functionality but fixing the old code, making development time exponential.
My advice to you would be to, without telling the programmers how to do their job, try to get a handle of how the program works at a general level and you should soon be able to see how new functionality would modify that behavior and thus provide a reasonable estimate on how long it would take to do it. Combine this with their estimates (double the highest), and you start getting a better idea of how to estimate development time.
I hope that helps!