I'm a junior developer and I find it hard to estimate how much time it takes to finish a bigger software project. I know how to structure the architecture in general, but it's hard for me to know what details I have to do and what problems I have to solve. So it's hard to estimate how much time it will take to finish a bigger project, because I don't know what problems I need to solve and how long it takes to solve them.
How do I explain this to a person that is not a software developer?
You could ask him/her to estimate how long it would take for her to access some far away location in an uninhabited corner of the world. As an extreme example, let's choose some lesser known peak in the Himalayas, where very few (if any) people have ever climbed on. She would need an awful lot of preparation plus practice before even starting the journey, plus a bunch of permits, each of which can delay the trip for months to years... and a good support team... then once up on the hill slope, she would need to wait and pray for good weather to start climbing towards the peak... etc. etc. Most of these are hard to impossible to estimate, even with prior experience.
And the point is: each software project is a bit like climbing a new mountain, where no one has been before, so no one has direct prior experience. Seasoned developers may have gathered experience on more or less similar projects, but there will always be new elements and surprises - otherwise, if a software project were exactly like some previous one, there would be absolutely no point doing it.
Have you explained that to the person? You are the professional software engineer, so the person that you are building software for should be considering your knowledge and feedback when it comes to the design and implementation of software systems.
The Cone of Uncertainty is probably a good starting point. Software projects are hard to estimate until more of the details are known, which happens later in the project. In addition, changing requirements will also change estimates. Your initial estimates at the beginning of a project will have a large amount of variability.
You might be interested in other estimation techniques, too. You mentioned that you are only a junior developer. Generally, more experienced developers have a better ability to estimate since they have seen more problems, solved them, and (hopefully) kept track of estimate versus actual time. You could take advantage of this using estimation techniques such as wideband delphi or planning poker.
As a junior developer, start tracking estimates and actual time now. You might be interested in reading about the Personal Software Process developed at the Software Engineering Institute. The core PSP books are A Discipline for Software Engineering, PSP: A Self-Improvement Process for Software Engineers, and Introduction to the Personal Software Process. I believe that Introduction to the Personal Software Process would cover the topics that you would find most helpful. I think it's generally overkill for most developers, but it does have some good ideas and good practices that can be pulled out and used in order to improve personal productivity and hone various skills (including estimation) that you'll continually use over your career.
If you will be doing a lot more work in estimation, I would highly recommend two of Steve McConnell's books: Software Estimation: Demystifying the Black Art (focuses on estimation as an art and science) and Rapid Development: Taming Wild Software Schedules (general software engineering process and project management topics).
Refer to literature. There's a huge pile of complex and often contradictory material, which, as proven by practice (experiments), doesn't work as expected. At least academics are swayed by a pile of books.
Must-read: http://en.wikipedia.org/wiki/The_Mythical_Man-Month
The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping.
Brooks' observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later counter-intuitively conclude to have delayed the project even further. He also made the mistake of asserting that one project — writing an ALGOL compiler — would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it." The book is widely regarded as a classic on the human elements of software engineering...
I've met people who claim they can estimate software, but I don't know how they do it. Neither have any of them been able to explain how they do it.
As a consultant, my clients often require me to work on a fixed-bid basis. Thus I need to estimate so that I can prepare a realistic bid. I have never once succeeded at this. One would think I would overbid as often as I underbid, but that is never the case. The result is that I often lose a lot of money on my contracts, and end up earning a lot less than I would if I were working for a company as a regular employee.
I've been searching for many years for a book that would teach me how to estimate software, but I have yet to find one.
As for explaining this to someone who is not a coder. You could point out that no one in the industry is consistently able to meet their estimates. It happens all the time that new software products are preannounced, only to ship months or years after the date that was originally announced.
If a big company like Microsoft can't figure out how to estimate the time that goes into producing its own products, how can I?
Whether I'm being paid by the hour or by the job, my clients always expect me to provide these estimates. I don't know how they expect me to produce them when such estimation is not taught anywhere, and I have no rational basis for my estimates.
Find out what they plan on doing with this estimate. In their mind they want to know if it will take months or years and you're trying to get the exact hours (Typical Engineer).
See if you can work on a piece of the project and then put together a better estimate if needed.
If they keep pushing, you're going to be forced to itemize as much of the tasks as you can an apply a time frame. Tell them you will let them know as soon as you see anything that may affect the estimate and make adjustments. People usually try to avoid surprises.
Estimation of the entire project's time is usually performed by the project manager not the programmer.
You can build an argument based on the fact that the project manager has the full list of tasks required. Without this list, any estimation will be a 'bad' guess.
Also, time depends on many factors such as how many people are available and the scope of requirements, which you did not say you have. Architecture alone is not enough.
Another point you could make is that software engineering is still in its infancy compared to other fields of engineering, and has not matured enough for estimable development techniques to have appeared.
Software engineering is also in a continuous state of flux. By the time a technology has been around enough to be considered mature, it is often abandoned in favor of some new technology. That prevents anyone from gaining enough experience with any one technology to be able to produce reliable estimates.
Contrast this with construction estimation. That's a very well-understood problem, not just because contracts are awarded based on bids, but because humanity has been building things since the dawn of civilization.
