When a customer says that he has a smaller project than the one I just did, don't pay attention, and think about the quote, rather than simply estimating the time as less than the previous project.
Yesterday, I did a project for a friend (one who let me have better access than average to the real estate listings) and it took an hour and a half and was 107 lines of code. He wanted to pay for that one, but I thought it was a fair exchange for getting the real estate listing access.
Today, I did a "smaller" project, that was 367 lines of code, and it took 3.5 hours. Hrm.
On a related topic, I never understand the estimates that say coders can only do 10 lines of working code a day or whatever they claim. These projects have 1.1 and 1.8 lines per minute, and they have been reasonably tested with a couple thousand lines of input.
I don't really think it is just that I am some great programmer, but presumably there is reason behind the logic that says coders can't code that fast.
These projects were in PHP, but I have noted similar things in the past in C and when writing assembly language.
Posted by
Jon Daley on
March 20, 2008, 9:27 pm
| Read 5796 times
Category
Programming:
[
first]
[
previous]
[
next]
[
newest]
Granted, I haven't coded anything in nigh unto 30 years, but to me, "lines of code per minute" is meaningless. If the project was something familiar I with and not too complicated, I could whip out code very quickly. On the other hand, there were projects where if you factor in all the time spent designing the system, coding was very slow indeed.
I believe those numbers include the overhead of time in meetings. In big companies this is significant. I think it also includes bigger projects with multiple participants - which of course take more coordination, and thus more time.