Code payment

Paying by the line count sounds like a really bad idea. Seriously you'd just create a huge amout of useless code so you got paid decently. Pay people by project, or by the hour ... or a mix, but just by code size seems wrong to me. You'd get bad programers getting paid more than good ones which isn't what you want.

asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");...etc.

Yeh seriously dont pay per line since it is in no way a good reflection on the amount of time, effort, and skill that went into creating the code. In fact quite the contrary, often the smallest most efficient code is the stuff that takes the longest to program.

Well there's no way to really monitor someones hours that isn't in the same vacinity as you but I suppose I could split up what needs to be coded and pay a certain amount for each portion.

Quote:

Original post by Motorherp asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");asm volatile ("nop");...etc.

If I were to pay someone for lines of code I certainly wouldn't pay for something like that. I would make sure it's decent code. I'm a fair programmer but definately not an expert.

Quote:

Original post by fieryhen Well there's no way to really monitor someones hours that isn't in the same vacinity as you but I suppose I could split up what needs to be coded and pay a certain amount for each portion.

Yup this is the most sensible thing to do. First off make a complete and concise list of everything you require the program to be able to do along with a rough time schedual which you should give to any programmers interested so they can sit on it for a few days and think it over. Its not always obvious from the beginning how complex it can be in the code to acheive certain goals so its important to give them time to consider it so that you dont end up setting unreasonable targets which cant realisticly be acheived. After this you should then barter with the programmer over time limits, payments, and any check points you might want to setup to measure progress. When you've both agreed on something sign the contract.

It's unreasonable to pay by lines of code.

One line of code could take several days to write, if it's a bugfix and that's how long the debugging took. This can happen in real applications.

You can't obviously know, looking at the one line of code, how long it would have taken to write. You can know how long it took to type, but in my experience, this is not relevant.

Mark

You should pay for worked hours (you might have to find a way to get quick informations on what have been done - it is easy to say "I worked for 4 hours" but then the person should justify what he did during these four hours). Paying by line is not possible - for example, what if I'm fixing a bug? What if I do a lot of design? And so on. And 5$ per 1k line is a bit low. Since I began to work at my new office, I wrote nearly 100 lines of code (fixing 4 different bugs). In 12 days - 96 hours. At this rythm, I might need as much as 120 days to earn 5$ (my company values my work a bit more [smile]).

Quote:

Original post by fieryhen If I were to pay someone for lines of code I certainly wouldn't pay for something like that. I would make sure it's decent code. I'm a fair programmer but definately not an expert.

His point is that "lines of code" is a crappy metric. I would draw out a list of one-day features and decide a pay scale proportional to those, and pay by the module.

One thing that I've seen some competent Agile shops do is decide upon a point system (this module is 5 points, the other is 10) depending on difficulty and allocate a fixed number of points for that week (say 20).

If you are going to have people work on their own, I really suggest breaking the game down into projects and pay people by the project. Then you know people are not cheating on hours, and you do not have to scan the code.

As others mentioned, paying by line is not a good idea.

And fieryhen, I've seen some code in my professional career that has been worse than that.

Seriously, pay by project, not even by hour.

This is an over generalization coming.

Software development follows the 20/80 rule. 20% developing, 80% debugging. From what I last heard, the average software developer writes 200 lines of code a day (8 hour days).

Let's state that your program has 1000 lines of code. That's 40 hours right there. Assuming you make $5 (we're going just legal here, not professional development), that comes out to $200 for a 1000 line program.