How Programmers calculate hours of Work?

23 replies
Hi,

I was wondering how programmers calculate hours worked for a project. do they have a standard ?

and what is that standard?

does an hour for an slow programmer is different for a faster programmer...?

I believe in should be a standard
#calculate #hours #programmers #work
  • Profile picture of the author SteveSRS
    eeh I'm not sure of your question as its a bit weird

    1 hour = 1 hours of course..

    Also a 'fast' programmer is not always (more often not) better then a 'slow' programmer.

    If you are concerned about this when hiring NEW programmers just do on project base on smaller jobs and check their code and how fast they did it.
    {{ DiscussionBoard.errors[7358186].message }}
    • Profile picture of the author FirstSocialApps
      Originally Posted by SteveSRS View Post

      eeh I'm not sure of your question as its a bit weird
      I think perhaps he is a programmer and is looking to figure out how he should bid on jobs ... well that might be what he is asking. IDK for sure. My thought is that he is saying that if he is a fast programmer then he is kind of getting screwed. I can see this on freelance jobs.

      For example:

      Person A bids $45 per hour
      Person B bids $90 an hour

      To the buyer it may look like person B costs double what person A does, but if person A takes 2x as long because of lack of exp etc. Then they are actually the same price. Its just that person B is 2x as efficient. But to a non tech buyer it would be hard to understand that.
      {{ DiscussionBoard.errors[7358340].message }}
      • Profile picture of the author Nauman K
        Good Reply bro,
        Same happens to us, if we qoute $30 per hour then the client complaints it too much so you have to qoute less and spend more time on it which is not what I am satisfied with.
        but due to clients and work one can't to anything as client love to hire some one on $10 lol.
        Thanks
        Nauman K
        {{ DiscussionBoard.errors[7358641].message }}
  • Profile picture of the author wayfarer
    My personal standard is to only work by the hour. But to compare my hourly rate would be unfair, because everyone has to determine their own market rate. Your rate should be relative to rates normally charged in your country/region. Charge less if you have less experience, more if you have more. Do your own research and you'll have a much better chance of doing well.

    And yes, 1 hour = 1 hour. Either use a stopwatch, or use an online hourly timesheet which tracks it for you. I use Odesk.
    Signature
    I build web things, server things. I help build the startup Veenome. | Remote Programming Jobs
    {{ DiscussionBoard.errors[7359479].message }}
  • Profile picture of the author SteveJohnson
    I almost NEVER work by the hour - why open a can of worms when you don't have to? The only exception to that is when I'm unable to reliably estimate how long a particular task will take. My clients NEVER see my internal timesheets for a project.
    Signature

    The 2nd Amendment, 1789 - The Original Homeland Security.

    Gun control means never having to say, "I missed you."

    {{ DiscussionBoard.errors[7359871].message }}
    • Profile picture of the author FirstSocialApps
      Originally Posted by SteveJohnson View Post

      I almost NEVER work by the hour - why open a can of worms when you don't have to?
      Yea I agree, when I was freelancing full time I really tried to avoid hourly jobs. Just the simplicity of Ill do this, you pay that. no surprises was appealing. Of course this comes with its own set of issues. You need a well set out spec sheet to give a proper flat rate bid and you really have to watch out for scope creep.
      {{ DiscussionBoard.errors[7360413].message }}
      • Profile picture of the author Brandon Tanner
        As someone who has been on both sides of the fence (I have been a freelancer, and I have also hired many freelancers), I would strongly advise you to never buy or provide services based on an hourly rate. If you do that, you are just asking for non-stop headaches.

        The exception would be if you have worked with someone long enough that you REALLY trust them. But in most circumstances, it's best to just agree on a single quote for the entire project.
        Signature

        {{ DiscussionBoard.errors[7360660].message }}
        • Profile picture of the author luckyman#9
          There are generally two types of bids: Fixed Fee and Time and Materials.

          Fixed fee is where you say to the client that you'll build that website for $4,000. Assuming $100 an hour, the developer is expecting to spend 40 hours on the site. Of course, they would be smart to tack in 10% for overhead like project management, communications, invoicing, etc. So really, they are charging $90/hr for actual work. Now, if they misjudged and something took them an extra 10 hours, their hourly rates goes down again and they get to $72/hr (10% admin time, 10 hours over budget). When the client says, oh, wait please change this, then 4 more hours are added. Plus add in the extra 6 hours of surprises during deployment since the client didn't tell you something and you are another 10 hours over budget. To recap, the developer bid $4,000 for 40 hours worth of work, but it really ended up being 60 hours plus a 10% premium for admin (we'll keep that on the 40 hours). That puts the total at 64 hours. 4000/64 = $62.50/hr actual vs. the $100 perceived. Add to that the freelancer has to cover their own un-utilized time (which most consulting companies peg at around 30% to be safe) and that $100 really got a lot closer to $40.

          Time and Materials can be a drag on the client if your developer isn't good or honest. If they are good and honest, then it comes out to be the most fair situation. In the above example a good developer would eat some of the time that they mis-judged as good faith (especially if they are learning something they should reasonably know, or they just didn't see something they could have). That same good developer would tell their client that asking to change the theme at the last minute will actually cost them a 2-day delay and $1,600 extra. That is quite motivating to contain scope creep and ultimately can help a client.

          Bottom line: <rant>STOP HIRING CHEAP DEVELOPERS. Find good developers that are a pleasure to work with and who are HONEST and operate with INTEGRITY. Then (shocker here) PAY THEIR RATES without nickel and dimming them. Without fail every project I've seen that has tried to skimp on development rates has either failed outright or produced lackluster results.</rant>

          If you have a bigger project then hire one great senior developer and one junior newbie. Blend their rates and have the senior manage the junior. Be sure the senior is off-loading the easy stuff the junior. Win-win. Scale as necessary until you reach a certain number of junior devs like 3-5 junior to one senior. But in those situations make sure your Senior actual wants to play team lead. If you are getting up to and past that size, then you already know everything I've said.

          Sorry- I've been at this a long time. I have many multi-thousand hour and 7 figure projects under my belt and little ones too.

          From a developer's perspective it's easy. If you are new, price yourself accordingly to get work. Then showcase that work and use it to get better work. Keep raising your rates as your work gets better and you have better social proof.
          Signature

          My latest project: http://www.heavenlyyoga.com/

          {{ DiscussionBoard.errors[7363845].message }}
  • Profile picture of the author bhmseoservices
    Working by the hour can often cause headaches. I use time management for all my clients and just charge one amount and give the clients a deadline. At least this way I keep taking in clients and not worry about hearing them complain.
    {{ DiscussionBoard.errors[7359965].message }}
  • Profile picture of the author Mike Ogbin
    I think that the best method is to hire programmers according to the tasks not the hours. The fix price is much more comfortable for you than paying them by hour.
    Signature
    Speedy Up - Jumping game that change your mood and put smile in your face :)
    {{ DiscussionBoard.errors[7371612].message }}
  • Profile picture of the author ronyjones
    You should actually know the quality of code the developer is writing and his efficiency while development, before you outsource the work. The hours for particular project is calculate by the developer himself of the Project Manager or a Team leader under whom the developer is working. As they understand better how long will it take them to do complete the task.
    Later management decides the cost for the particular developer, depending on the Cost company is spending on the particular programmer. Management simply adds there profit and send the quote.
    {{ DiscussionBoard.errors[7372524].message }}
  • Actually in some cases we can't predict this work will be completed with in ---hrs. Because some client's made some changes after we completed that. We have to do that also.
    Signature
    seo services , website developing services contact subashcseo@gmail.com skype anushasubash
    {{ DiscussionBoard.errors[7376546].message }}
  • Profile picture of the author umrbd
    As a programmer I have worked on several hourly and fixed prices projects. In hours based projects you usually install a time card software which records your time while you work on the project and also send screen shots of your screen to the client, to let your client know that you are actually working. But, personally I firmly believe that freelancing sucks, if a programmer hate his skills he can start freelancing to make them vanish. You become a good programmer when you experiment a lot unluckily the freelancing clients don't let you do it. Instead you should get different kind of projects based on certain business logics by selling your services or make your own products. This is best
    {{ DiscussionBoard.errors[7378184].message }}
  • Profile picture of the author Didil
    As a software developer I can say that it truely depends on the honesty of the person as luckyman#9 said. You really have to build a relationship with the person. I only work with clients I enjoy working with, I love my job and would never overcharge them on fixed price nor on hourly price projects. Do a small project with the person, maybe a few hundred bucks at stake, see how it goes.
    {{ DiscussionBoard.errors[7378267].message }}
  • Profile picture of the author kenzik
    Originally Posted by webeserve View Post

    Hi,

    I was wondering how programmers calculate hours worked for a project. do they have a standard ?

    and what is that standard?

    does an hour for an slow programmer is different for a faster programmer...?

    I believe in should be a standard
    An hour is an hour. There is no standard rate, if that's what you mean.

    I'll assume that by slow vs fast you still want quality regardless of how fast they churn out code. That being the case, if quality is equal, it just comes down to rate.

    Suppose Programmer Slow Joe charges $50/hour and Programmer Lightning McQueen charges $100/hour.

    Slow Joe tells you it will take him 3 hours to do the project and McQueen says it will take him 2 hours.

    In this case, Joe will charge you $150, but McQueen will charge you $200. Essentially, you are paying a premium for getting the job delivered sooner if you go with McQueen.

    In reality though, quality varies. A lot. And you can't tell by the speed of the programmer. As a career software developer, I've seen fast sloppy code, fast quality code, slow sloppy code, and slow quality code. I've seen it all.

    I've seen code that works, but can't easily (inexpensively) embrace new features.

    So really, what are your requirements? Does it just have to work for this project? Plan on adding stuff later? Are you selling it as a one off? Will you need to support it?

    Software is complex. Typically, the more you are paying, it is because you are paying for the experience and wisdom that will help ask the right questions to make sure you get exactly what you need. The old saying definitely applies here: You get what you pay for.

    So great, you say, now what?

    Get referrals. No matter who is doing the work, get referrals. The more sizable and complex the project, the more you want to lean on a higher rate programmer. The smaller and more "throwaway" the project is, you can pay less and require less referrals.
    {{ DiscussionBoard.errors[7379982].message }}
  • Profile picture of the author davetrebas
    I learned over the years if it is fixed fee then make my best estimate and double it. Also, never deliver anything without a firm contract in place with progress payments.

    Also, if they did not have an rfq (request for quote) I would offer to write it as time and materials for them being sure to anticipate featureitus (could you just do this one little change) Many times the project manager would call requesting a "minor" change and I would point them to the spec saying that it was beyond the scope of the job, but I would be happy to bid on a change request.

    One difficult client called me 7 months after delivery with a bug that they wanted fixed (I gave a 6 month window for free bug fixes.) Told them I would call back, verified the bug and fixed it in about 10 minutes.

    Called back and told them it was a very difficult bug and it would cost $2,000 and take two weeks to fix it. They agreed.

    Marked my calendar. Two weeks later delivered the fixed software and invoiced them. They were happy to pay.

    Normally, I would have just fixed it, but they had given me so much grief during the development phase that I felt entirely justified.

    My other advice is don't be hungry to the point where you will take almost any job at any rate. Learn to recognize certain personality types like the "chisler" and be willing to walk away. Some people are just psychic black holes and will suck the life right out of you. You are much better off to just say "See yah, by" Then don't answer their calls or emails.

    Just my experience. Some lessons cost more that others. Good luck.
    {{ DiscussionBoard.errors[7425230].message }}
  • Profile picture of the author CreateSoft
    Originally Posted by webeserve View Post

    Hi,

    I was wondering how programmers calculate hours worked for a project. do they have a standard ?

    and what is that standard?

    does an hour for an slow programmer is different for a faster programmer...?

    I believe in should be a standard
    Determining how long a project will take comes with experience and familiarity with the project's technical challenges.

    When I analyze a new project to determine how long it will take, I look at the project spec and then compare it to past things I've worked on. From there, I can estimate if it's going to more time, less time, or about the same time.

    If it's something new that I've not done before, I try to break the project down into sub-projects, and then estimate each of those sub-projects independently. Then I will add up those estimates to get a total estimate. For the sub-project that contains the new technical challenge, I will just guess, and pad it around 25-50%.

    When it comes right down to it, estimating project duration is all about SWAG: Scientific Wild A__ Guess. You don't just guess, but do your best to guess based on previous performance.

    Once you have an estimate, then you can calculate how much to charge a client (or report back to your boss if your not a freelancer).

    For fixed fee, pad your SWAG a little bit more to account for client changes (which will happen) and unknowns (which also happen) and other unforeseen challenges (yes, these happen too).

    For hourly, it's less of an issue as long as you communicate when you run into a snag that will cause extra hours.
    {{ DiscussionBoard.errors[7430680].message }}
    • Profile picture of the author ClicProject
      What CreateSoft said, except we usually underestimate how much to add for unforseen issues and end up working for much less than we should whilst the client complains about how expensive it is.

      Sorry, little rant there.
      {{ DiscussionBoard.errors[7433755].message }}
  • Profile picture of the author CreateSoft
    You make an excellent point ClicProject about underestimating. I had a manager who mentioned to me that I tend to underestimate too much and to start padding in extra time, especially when I'm computing estimates for a team and not just myself.
    {{ DiscussionBoard.errors[7434126].message }}
  • Profile picture of the author MikeBailey
    Banned
    I am not a programmer but I do web design and I calculate my work hours by the moment I start the project til finished. Whether it takes half a day or half a week just add those hours up!
    {{ DiscussionBoard.errors[7434502].message }}
  • Profile picture of the author Rideem3
    Programming slowly is actually not a bad practice. This allows you to make sure that the code you wrote is accurate and doesn't contain errors.
    {{ DiscussionBoard.errors[7449583].message }}
  • Profile picture of the author Hilal Shakarchi
    I work as a software developer and we give estimate in days for the client ( a day is 8 hours) . It's better to overestimate than underestimate. The project manager usually consults the developers to inquire about the amount of time it would take to do the development. You also have to add analysis, testing and a buffer (in case something unexpected happens) time in your estimation. If you are a project manager it would be good to use a methodology called "Scrum" every mourning where all developers will talk about what tasks they accomplished yesterday and what they plan on accomplishing today.
    {{ DiscussionBoard.errors[7459137].message }}
  • Profile picture of the author Tyler S
    This is always pretty subjective. I like to hire programmers based on a fixed priced, so I know exactly what I'm paying. Hiring and paying by hours tends to get a little confusing for both parties.
    {{ DiscussionBoard.errors[7459146].message }}

Trending Topics