I'd just like to reinforce Abigails comments with my own personal situation. When I first started my job I rarely got requirements, my line manager was happy to give me a verbal list of things it should do (in general) and then make modifications once he had seen the *prototype*. Fortunately I rapidly learned to ask directed questions which meant that I only ever really suffered from feature creep rather than from sweeping changes.

Nowadays, he has realised that if I build by guesswork he doesn't get what he wants so I do get formal requirements.

Throughout the both of these periods, however, I would agree what he would get and when. At that appointed time, I would provide the work and he would either be happy (or not). At no time have we discussed lines of code. What you deliver is most important - not how many keystrokes it takes. After all, why would the client care?

To put it a different way, the industry we work in emphasises code re-use. Once your requirements are more concrete you will (I assume) create a more concrete design to help with code-reuse. So if you spend two days producing 400 lines of code which then gets re-used 40 times throughout the remaining 10 days of your work - how many lines of code does that count for? 40*400?

I'm also reminded of a dilbert cartoon (can't remember the date so no link) where the phb offers bonuses based on bugs fixed. Spend the first week coding 80 bugs and the next two days fixing them and earn yourself a new boat (or whatever). As you can see, it just doesn't work ;).

Just my 2p,

SP