That is why developers that plan their code before using the keyboard tend to outperform other developers. Not only do only a few developers really plan out their code before coding but also years of experience do not teach developers to learn to plan. In fact studies over 40 years show that developer productivity does not change with years of experience.
Interestingly enough, there are methodologies that have been around for a long time that emphasize planning code. Using PSP has been measured to:. If you are interested there are many other proven methods of raising code quality that are not commonly used see Not Planning is for Losers.
See the original article here. Thanks for visiting DZone today,. Edit Profile. Without actually checking my copy of "The Mythical Man-Month" everybody reading this should really have a copy readily available , there was a chapter in which Brooks looked at productivity by lines written. He did point out that productivity could be expected to vary. He said that compilers were three times as hard as application programs, and operating systems three times as hard as compilers.
He seems to have liked using multipliers of three to separate categories. I don't know if he appreciated then the individual differences between programmer productivity although in an order-of-magnitude argument he did postulate a factor of seven difference , but as we know superior productivity isn't just a matter of writing more code, but also writing the right code to do the job.
There's also the question of the environment. Brooks speculated a bit about what would make developers faster or slower. Like lots of people, he questioned whether the current fads interactive debugging using time-sharing systems were any better than the old ways careful preplanning for a two-hour shot using the whole machine. Given that, I would disregard any actual productivity number he came up with as useless; the continuing value of the book is in the principles and more general lessons that people persist in not learning.
Hey, if everybody had learned them, the book would be of historical interest only, much like all of Freud's arguments that there is something like a subconscious mind. It's easy to get a couple of hundred lines of code per day.
But try to get a couple of hundred quality lines of code per day and it's not so easy. Top that with debugging and going through days with little or no new lines per day and the average will come down rather quickly. I've spent weeks debugging difficult issues and the answer being 1 or 2 lines of code. It would be much better to realize that talking of physical lines of code is pretty meaningless. The number of physical Lines of Code LoC is so dependent on the coding style that it can vary of an order of magnitude from one developer to another one.
In the. NET world there are a convenient way to count the LoC. Sequence point. A sequence point is a unit of debugging, it is the code portion highlighted in dark-red when putting a break point. With sequence point we can talk of logical LoC , and this metric can be compared across various. NET languages. The logical LoC code metric is supported by most. For example, here is a 8 LoC method beginning and ending brackets sequence points are not taken account :.
The production of LoC must be counted in the long term. Some days you'll spit more than LoC, some others days you'll spend 8 hours fixing a bug by not even adding a single LoC. Some days you'll clean dead code and will remove LoC, some days you'll spend all your time refactoring existing code and not adding any new LoC to the total. In this condition, my personal score over the last 5 years coding the NDepend tool for.
NET developers is an average of 80 physical LoC per day without sacrificing by any mean the code quality. The rhythm is sustained and I don't see it decreased any time soon. For those who hates counting LoC I saw many of them in comments here , I attest that once adequately calibrated, counting LoC is an excellent estimation tool.
After coding and measuring dozens of features achieved in my particular context of development, I reached the point where I can estimate precisely the size of any TODO feature in LoC, and the time it'll take me to deliver it to production. Total lines: Let's assume I don't write any comments at all, that is, With your ratio, that code library would take me around days to write. That's 29 years. I certainly didn't spend 29 years writing that code, since it's all C , and C hasn't been around that long.
Now, you can argue that the code isn't all that good, since obviously I must've surpassed your 12 lines a day metric, and yes, I'll agree to that, but if I'm to bring the timeline down to when 1. You can have a top notch programmer churning out code in the order of thousands of lines a day, and a medium programmer churning out code in the order of hundreds of lines a day, and the quality is the same. The total you want is the balance. Amount of code changed, versus the number of bugs found, versus the complexity of the code, versus the hardship of fixing those bugs.
Which means: eg. Divide by just the coding period, and you'll get closer to what people are quoting. At least that is my experience with larger teams. So it seems my numbers are not an outlier. So how much code do programmers average per day? Capers Jones measured productivity of around 16 to 38 LOC per day across a range of projects. My data is based on the current sizes of the code bases. I have just spent several months rewriting large parts of PerfectTablePlan to work with the latest version of Qt, which involved deleting large swathes of code.
I only counted code in products shipped to the user. All the code is cross-platform for Windows and Mac, which makes it more time consuming to write, test and document. Programming is only one of the things I do. As a one-man-band I also do marketing, sales, QA, support, documentation, newsletters, admin and nearly everything else. I have also done some consulting and training not directly related to my products in the last 12 years.
August 01, pm Subscribe [9]. First of all, I work along! Tyler Diaz 24 posts. Roughly, lines. I would suggest that that lines of code per day is not a good measurement of productivity.
CrimeCleaner 10 posts. I would have to agree with the previous reply that lines of code per day is not a great tool for measuring productivity, but its just a fun question. Shrike67 16 posts. Stock Blog 1 posts. About 50 lines per day. Not many recently!
0コメント