Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
sorry, that makes 30 lines per day. I think production related tasks should not be considered into development time but anyway. I got the answer to my question, thanks a lot!
No problem, happy to help.
BTW, if you prefer to estimate based on coding time alone a good rule of thumb is that coding is roughly 20% of the total time. In your estimate you estimated 2 weeks for coding so I would have said totally 10 weeks to complete the task. Based on that your estimate of 2 months is reasonable considering that TCP and IP are well understood protocols and most of the required algorithms are published and well known.
If a trainstation is where trains stop, what is a workstation ?
alexfru wrote:3 lines per hour comes out as 3*8=24 lines a day, which is not far from the average figure (~10 LOC/day in the industry).
Everything has its cost:
finding a/the solution to the problem
understanding the existing code
working around/fixing/rewriting the existing code
actually writing the code you need
reading docs
debugging/troubleshooting
writing tests
running tests
code reviews
working with other people otherwise (helping out, mentoring, presenting, etc)
writing docs
meetings
various forms of support
Some days you can get 1+KLOC, others 0. The average (over a year, let's say) tends to be closer to tens.
If you think 3 lines an hour is low, it means you don't have to do a lot of the above, which has its implications, most often in the form of code quality. Or you're a solo programmer superstar.
Can't agree more, those who starts fast gets stuck evrntually, one of the most horrible programs are written by those who does not give a crap about quality.
Once I got hired as a new sw engineer and was assigned to root cause where plugging certain USB device caused system to freeze. I spent 4 weeks learning inside out how USB sub system initialise and ask its data structures and eventually nipped the bud where I just corrected one line where it hard coded certain variable size and doing so it was overflowing the buffer and erasing entire USB area. So that was 5 week 0 lines added, 1 line changed.
Funniest and ridiculous part is core server team refused to check in my fix because they were afraid doing so will have side effect on many server models. The company was Dell and you go figure!
Last edited by ggodw000 on Sun Jan 24, 2016 5:57 pm, edited 1 time in total.
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
alexfru wrote:
If you think 3 lines an hour is low, it means you don't have to do a lot of the above, which has its implications, most often in the form of code quality. Or you're a solo programmer superstar.
I must be living in another world because I am not superstar programmer by any way. I write some code, then I go take a coffee, relax and do other stuff.Or maybe you talk about coding in assembly language, then this is another story, I was talking about C. One of my biggest projects right not surpassed 20,000 lines of code. I have 2 years writing it and I do not write every day. In fact, it has been on standby for 3 months. If I use your formula of 3 lines per day, then 20,000 / 3 = 6,666 days / 365 = 18 years. That's way far from the truth. The effective working days would be around 6 months or so for this project, if I take out all the days it has been on hold because I was doing something else. If talking about quality I don't have much of the segfaults, valgrind is a good help for making your code stable. I also comment a lot inside the code because I am myself sometimes forgetting what I wrote. There have been a lot of projects for example like Napster, which have been made by one programmer very quickly, so , 3 lines of code per day is absurd. As I say, the key here is: to know what you want to achieve. And it will be written very quickly.
when you measure your code quality in terms whether you segfault or not, that ain't look reasonable. Not doing segfault should be taken for granted not something for taking credit. Software quality is measured on how well documented and handling errors which affects the maintenance cycle.
Do you comment your code regularly such that someone else can easily pick up without looking at your code line by line, or if you yourself abandon your project and year after you can pick up without refreshing every line by line? Does your function and api act like a black box where user only needs to know input output, what variable it destroys and overall purposes I.e. if not then it is likely to be.. well you know what I mean
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
