Programming extortion or poor estimating?

Dec 20, 2009

For a project we have at work, we needed to have some Java code written for encryption. The tool we have has example code for it, but it wasn't quite what I wanted. So, one of our developers got a quote from the company that put together the example to change the code to what I wanted as I don't know Java. The quote to modify the code was 4 hours @ $155/hour. While I don't have a problem with the hourly rate, I thought the 4 hours was utterly ridiculous as the example code was almost what we needed and the encryption libraries are already built into Java. In addition, getting $620 approved for this might have been more trouble than it was worth.

On Friday, I sat down, did some Google searches, installed NetBeans, and within an hour, I had the Java code working. Prior to this, I had never written a line of Java code. However, Java, like most languages I work with, has a very similar syntax that for my very small piece of code, was quite easy to understand.

So the high quote was one of three things. First, they might not have understood the request (I just double checked the email exchange and it seemed quite clear to me). Second, they could have been extremely poor at estimating. I've been writing software for many years now and my estimating is sometimes way off whack, but that is usually for big tasks and tasks where I'm starting from scratch, not sample code. My worst estimating that I ever did, I estimated 2 weeks (80 hours) to complete a bridge between a Mac application running as a native Intel application and a PowerPC plugin. Somehow I managed to complete this in less than 4 hours. However, I wasn't and am still not aware of any commercial shipping application that has this functionality besides what I wrote, so writing this was a complete unknown. Third, the quote could have been high because they may have thought we had no other option and when you're a monopoly, you can charge whatever you want.

Initially, I quickly jumped to the conclusion that the third option is what happened. After thinking about it and throwing out the other 2 options, I'd like to say that the 3rd option wasn't the real reason, but it is really hard to discount it.

Comments

December 30th, 2009

ooglek

I tend to overestimate small quotes. While most times you could complete it in an hour, you have to spend the time looking at the code and the project to determine how difficult it will be. Figure that took about an hour of someone’s time. Then there is the task at hand, and not knowing if the example code actually worked. Then there is testing.

I don’t think a quote of 4 hours is unreasonable, especially if they would charge you less if it takes them less time. Small jobs like yours are often more complex than the customer states, and overestimating helps to dampen that a bit. Obviously you knew a lot about the project and to you it seemed simple (and it was), but to a developer with no knowledge of your real technical prowress, it can be a crapshoot.

December 30th, 2009

Scott Gruby

For really small projects, I personally start to prototype it before giving an estimate just to see where it will go. If I don’t get the work, oh well, but I have a good idea of the estimate. With this particular project, the developer had actually written the sample code that we wanted modified, so I would have expected a short estimate. Estimating is more of an art than a science; I’ve had a number of estimates that are so far off, it’s not even funny.

December 31st, 2009

This estimate seems very fair me me. I am manager of software development for a small firm. If done right, the development process includes documentation, peer review, unit test and all the other good programming practices that create functional and supportable code. Can the solution be coded in less that 4 hours, sure but if you want quality you have to allow for all the other non coding processes as well.