Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Time estimate to write a program? 1

Status
Not open for further replies.

abds

Programmer
Dec 13, 2000
46
0
0
US
My boss wants me to start giving him projections as to how much time it is going to take to write the programs he assigns to me.
I have almost no idea how to do this.
PS. Am I in the right forum?

We are drowning in data, but we are starving for information.
 
Not knowing your skill level, nor the complexity of the requested programs, I doubt anyone can help you with this problem. One thing to keep in mind though, when you estimate how long things are going to take, always base a "work day" on only 4 hours of actualy work, not 8.

This reduction of time in the work day accounts for time wasted at lunch, in meetings, chatting by the coffee machine, etc. So, if in your mind you think to yourself, "I can do this in 3 days." You need to schedule 6 working days.

And, if you manage to finish ahead of schedule, it will only make you look that much better. It's better to pad your estimated completion times and have time left over, rather than scurrying around on the last day, trying to make a schedule.
 
How long does it take to build a building?

You have given absolutely no information to help us answer your question.

1. Language
2. Your experience using that language
3. Your experience with other languages
4. Functionality of the program
5. File access method (database, flat files, etc.)
6. Your experience using that access method.
7. Standalone program or part of a system.
8. Software Maturity level of your organization.
9. Availability of development and debug tools.
10. Your experience with those tools.


Whatever you do, do _not_ fudge your estimate. Overestimating and coming in early shows you had no idea what you were doing.
 
How complete (detailed) is the software specification?

Is the specification firm or will your boss/client decide on changes to the user interface, features, etc. at any time?

If you have a good, detailed and firm specification, then you can begin to estimate completion times for blocks of the overall system.

Bernard Ertl
www.interplansystems.com - eTaskMaker project planning tool
 
Being both a professional hard-core techie and a long-time project manager, I know the dilemma you are faced with.

The previous posts give you clues on what to do and what not to do. However, since you indicate that you do not know how to do the task, perhaps you are overlooking the obvious first-step.

Ask your manager for help. By way of the post, it is clear that you do not yet know estimating. As goofy as this may sound, your manager may not know either. Working together, you will likely find a common ground that will aid you both to better understand estimating and its requisite skills.

Other tips with your manager:

You may wish to explain that you (and others on your team) need help getting an estimating practice in place.

You may wish to identify a metrics collection practice (of previous efforts) is needed to accurately perform one art-form of estimating.


Let me know if you need further help
dugger
 
You could consider a technique called "Function Point Analysis", which is too tedious to go into at this time in this forum.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top