I'm working as a web developer and I want to be able to determine if I'm efficient.

Does this include the how long it take to accomplish tasks such as:

  • Server side code for the site logic with one language or multiple php,asp,asp.net.
  • Client side code like javascript with jquery for ajax, menus and other interactivity
  • Page layout, html, css (color, fonts (but I have no artistic sense!))
  • The needs of the site and how it will work (planning)

How can i judge how long it will take to complete a website?

The site has CMS for adding and editing news, products, articles on the experience of the company. Also, they can edit team work, add Recreational Activities and a logo gallery with compressed psd download, and send messages to cpanel and to email.

You are starting from scratch except JQuery and PHPmailer.

How can I estimate how long the job will take, and how can I calculate the required time to finish any new projects?

I'm so sorry for many scattered questions, but I'm in my first experiment and I want to take benefits from the great experience of those who have it.


8 Answers 8


There is a lot to be said for detailed requirements. Everyone hates creating requirements documents but they are a very necessary evil. That being said, I've managed a lot of software projects over the years and I have a few methods that I've found make it much easier to estimate.

Personally I can't say enough about Microsoft Project. There are free tools with similar capabilities but MS Project is by far and away my favorite. Regardless of what project management tool you choose these methodologies should apply still.

  1. Create a list of high level tasks (CMS, site layout, custom coding, etc).
  2. Begin to add sub tasks and groups of sub, sub, sub tasks from the top level.

Ultimately what your looking for here is to understand everything that's involved. You won't get everything, you'll inevitably miss something, etc but that's not the point of the exercise. As you go through listing every task that needs to be done (put down things like Research X, Test X, etc) you'll discover tasks you never thought about as you go through it. Think of everything that has to be done from planning to building to testing to migrating to the customer.

Once you have all the tasks down you can start to estimate the time necessary for each item. Your times are an educated guess, make sure you pad them with 20-40% (or more) more time than you think it will take. The project management tool you use should have a concept of "Predecessors" or similar. This will allow you to link the tasks and indicate which tasks require other tasks to be completed first.

Now that you have tasks, time estimates and predecessors your project plan can "start" to estimate a timeline for you.

Project management essentially has two primary concepts. Either A, the project deadline should dictate the timeline or B, the project tasks should dictate the timeline. I am VERY much in the B camp. Many MBA types and "bean counters" will try to tell you when the project is "Due". They will also look at your plan and say "if we put 5 developers on task X it will get done in 1/5 the time". These theories are flat unusable in a software development world. While there are some cases a similar concept can be employed, it's generally a recipe for disaster. Imagine 5 people trying to modify the same file simultaneously. They will walk all over each other and even the most advanced source code management tools will fall far short.

OK, so you have an "estimate" now. Yes it's rough, no it's not complete and yes it will change (go back and add more time padding Now). Your probably also looking at the end date and thinking to yourself, the client / boss is going to go nuts when they see how long it will take. This is where you pause and take a deep breath. Not only have you thought throughly through what this project will take but you now have documented detail about WHY it will take this long. If they want to dispute time they have to go task by task to "cut out" time. I've found in 95% of the cases they won't have any interest in do this. You will also (in their minds) clearly understand what needs to be done and be seen as an "expert" in doing it since you have a detailed plan showing what it will take.

Notes: Make sure you put in tasks with estimates in hours where you can. It's hard to dispute something will take 8 or 10 hours. If you put 1 day they start trying to negotiate. There will be tasks that take weeks and months, just put them as such and be prepared to explain why. If you can, break that task into smaller sub tasks in hours / days.

Hope that helps! Daniel.....


How can i judge how long it will take to complete a website?

How can I estimate how long the job will take, and how can I calculate the required time to finish any new projects?

You can't.

Make up a schedule you feel comfortable with.

The best you can do is make small deliverables (weekly, every two weeks) and try to guess how many of those.

  • 2
    The key is small deliverables. Deliver small chunks you do have a feel for. The bigger the chunk, the harder it is to estimate, and the longer each run is, the harder other factors are to account for.
    – DaveE
    Feb 10, 2011 at 18:31

I believe that the agile estimation practices are the most accurate. Why it is successful is because it is based on estimating features in relative complexity, and then combine that with actual measured capacity.

A good introduction is this two part presentation by Mike Cohn: Part1 Part2. It is roughly 1:30.


Joel on Evidence Based Scheduling

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:


The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it...

  • I suspect that his EBS uses short tails and thus is susceptible to a Black Swan, and thus not that helpful. I will read it further and try to find where the weak spots are.
    – Job
    Feb 10, 2011 at 18:17

You probably can't do this on a rational basis, especially for a brand-new project.

See: Large Limits to Software Estimation Supporting material: Mathematical Limits to Software Estimation

In essence, estimation comes down to experience. You will estimate more accurately for new work in an already-existent software base. You will estimate less accurately for brand-new software. Every so often, you will grossly under- or over-estimate.


Remember, they call the estimates for a reason. Define tasks and start tracking your work. Try and develop some sort of baseline. Then practice making estimates and test the accuracy.

Not sure how you can compare yourself to others, but you can at least try to improve your development time and estimation ability.


You need requirements that are further baked to give an accurate estimate. You or a BA need to site down with the customer to determine what they want by elaborating on the bullet points you've listed above. Sit down and think about a list of questions for each of the above so you can interview the customer. Based on their responses you should start with a rough design and break down your tasks to the lowest level of granularity possible. Until you can break down each task to 16 hours or less then you need to make sure the customer understands that your level of confidence in the estimates is x%, most likely under 70% to start but this will come with experience.

Once you have your tasks broken down to the magical 16 hours or less I mentioned above you should be able to give an accurate estimate. Keep in mind that when you start, you will suck at estimating. You need to keep track of what you estimated in each of your projects so you can continue to improve. If you missed a major piece of functionality in one estimate then you need to remember that when you're putting together future estimates.

Web development does offer a level of uncertainty, customers will have their own personal preference on the style of the page and getting that out of them may prove difficult. You need to keep that in mind, when they review your work you need to be ready to tell them what it will take to accomplish the changes they've requested. Estimating a single project needs to be an interative process where your confidence increases with each iteration.


Practice will help. The first few times you do it you will get it really wrong, but if you try to understand what you got wrong each time and learn from it after a while you will get it right. (Or go out of business because you keep undercharging people)

Not the answer you're looking for? Browse other questions tagged or ask your own question.