36
17
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?
42
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.
More unknowns means more uncertainty. – surfasb – 2011-08-22T19:14:21.853
6Forget far away. Ask them to estimate - to the minute - when they will arrive home from work this evening. What if traffic is different, what if it starts raining, what if you receive a phone call while driving, etc.. If something so mundane, and performed as often as one's drive home, cannot be measured to any degree of accuracy - then how can we expect to do better estimating the time required to implement some complex software, which has innumerably more and more significant variables in it than a measly drive home from work. – quentin-starin – 2011-08-22T22:59:01.283
7@qes, I use public transportation, so I can tell with about 10% accuracy when I will arrive home - I think most SW project managers would be happy with this level of acccuracy ;-) – Péter Török – 2011-08-22T23:11:21.323
1Software project goals change too, so after they estimate the time they would need the OP could ask them if they'd still be on time after someone told them to switch peaks when they were half-way up the first one. – paul – 2013-05-28T13:29:53.323
17
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).
7
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...
2
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.
0
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.
Depending on the project management methodology, the PM might not even have the full list of tasks. In something like rolling wave project management, there's often a nebulous bucket that describes a very high level of task that's generally too large to estimate with any decent confidence level. As previous tasks are finished, tasks part of ths bucket are more well defined and can be estimated. In agile methods, tasks are frequently added, removed, or reprioritized at various points, again making it more difficult to estimate long-term milestones beyond a couple of iterations. – Thomas Owens – 2011-08-22T15:48:40.160
0
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.
1Steve McConnell's book Software Estimation: Demystifying the Black Art is really good on explaining how software engineers estimate. You can learn techniques and tools, but the only way to become good at estimation is to continually estimate, learn from your estimates, and repeat. As for no one consistently being able to meet estimates, there are organizations that consistently come within a couple of percentage points on their estimates - McConnell's book talks about organizations (often CMMI Level 4 or 5, with continuous improvement and detailed tracking) that achieve this consistently. – Thomas Owens – 2011-08-22T15:36:00.233
As for your problem with bad estimates. Do you keep track of your estimate vs. the actual time to completion? If so, determine by what factor you underestimate and multiply all your estimates by that number. – kubi – 2011-08-22T20:14:37.900
– kubi – 2011-08-22T20:17:22.017
0
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.
1Software engineering is still younger (by far) than most other engineering disciplines at an age of 42 years. However, there are a number of mature estimation techniques and tools. Wideband delphi (developed in the 1970s, made popular by Barry Boehm's Software Engineering Economics in 1981), function points (1979), SEER-SEM (roots in the 1960s), proxy-based estimation (used in the PSP, developed in 1994 at the SEI), and COCOMO (1981) and COCOMO II (1997). In a field that's only 42 years, there are already nearly 40 years of work done in estimation of projects. – Thomas Owens – 2011-08-22T19:40:23.843
4Curious: why is it your job as a junior developer to be explaining this to non-software developers? Is there someone in your work group or management chain who can help you with the process of convincing whoever it is you need to convince? – Alex Feinman – 2011-08-22T21:10:04.143
@Alex: No, it's not a person in the same company. Just a person with ideas to do a startup. And I'm the only developer he has contact with. – Jonas – 2011-08-22T21:12:33.080
1
Related: Getting non-programmers to understand the development process
– None – 2011-08-28T19:13:26.1872
Related: Sales Manager: “Why is time-estimation so complex?” See also How to respond when you are asked for an estimate? and How to learn to make better estimates? and What can I do to get better at estimating how long projects are going to take?
– gnat – 2013-05-22T04:59:04.040see also: How to explain to a non-technical person why the task will take much longer than they think?
– gnat – 2014-03-23T07:05:44.117