An interesting discussion may ensue if you suggest that it will take you as long to write the code, as it does your boss /client (or their agent) to write the specification for that code + 2 day per question that you have to ask to clarify the specification + 2 days for each line of existing code effected by the changes arising from your questions.

It is fairly easy to prove that code length is almost exactly proportional in complexity as a it's full specification and takes around the same amount of time to write down if you exclude delays through arranging meeting with clients, attending meetings with clients and waiting for answers and decisions with clients.

For each question that the specification is short of being a "full specification", adds the time taken to resolve that question. In some cases, resolving the question can be done

• from experience
• by lookup to some external material in your possession.
• by asking a "client expert".
• by asking the client to perform research.
• by performing the research yourself.

Emphasis that the questions involved are not "coding" or "implementation questions", only "specification", "requirements" and "client specific criteria and knowledge" questions. Ie. Those that you (or anyone not a part of the clients company and processes) could not be expected to answer yourself.

That all boils down to the idea that if it takes the client 10 days to write down (from scratch) a full specification of the program or system, then it is likely that I can code it in that same time. However, every time I encounter a question that I cannot directly answer from that specification, it will require me to break from the process of coding to reference an external (to myself) source.

Sometimes, with the items nearer the top of the list, I may "know" the answer from experience, or be able to look it up quickly and easily.

As you move down that list, the time required to find out the right source of the answer and arrange for contact with that source gets longer. If I need to obtain authorisation for the variation or amendment of specification as a result, the delay will be longer still.

At the top of the list, the delay maybe on the order of minutes. Towards the bottom the delays may be in the order of weeks. Travelling to the client to obtain information adds further delays, but even a using the phone, finding the right person to answer the question, finding them at their desk, conveying the question to them, understanding the reply, agreeing that you both have the same understanding of both question and answer, finding the "authorised person" to sign-off on the change to the specification that will result, all take additional time. If either party (you or they) have to do research to answer the questions, the delays grow again.

If you are sat at the same desk on a daily basis as a client agent with the knowledge and authority to answer questions arising, verbally, across the desk, delays are minimal. The further you move from this ideal, the longer they get. An office door between you, longer. A floor of the same building, longer again. Another building, site, town, country (also language!) all exacerbate the problem. Multiple persons to reference, different persons for authorisation, and approvals committees exacerbate further, and don't get me started on the situation where there is NIH syndrome or personality conflict!

The holy grail of e-mail is that it levels these playing fields, but I've yet to see that happen.

The ideal situation is that the person with the knowledge to write the specification is the same person with the authority to sign it off. In this case you stand a chance of having them understand the problems involved. They would understand how hard it is to encapsulate ideas into prose that stands up to scrutiny and may therefore have an inkling of how hard it is to convert that prose into code. If your authorising person is a "just give me the bottom line" type, your out of luck.

Until we have a specification mechanism that is as accurate and unambiguous as an engineering drawing or blueprint, the software equivalents of CAD for producing them & CAM for converting them to code, there will continue to be a 'finger in the air' aspect to drawing up schedules and any 'piecework' metrics like LOC & man-days are as meaningless as the figures you hear that it takes 12 men 1 day to build a BMW 3-series.

Just the development cycle of a new BMW takes years and costs billions and the cost to the consumer can only be reasonable, by amortising those development costs over million of units, so the costs and time scales of developing software can only be brought down to reasonable levels by the same factors of scale. There will always be customers that are willing to pay for bespoke development, but increasingly these will become the province of the military and medical fields where there is a large mass of emotion that allows cost to be secondary. Even with the military this is tending to move toward generalised solutions to a wide range of problems as is evidenced by things like the HUMVEE, JSF, JDAM and all the other military acronyms that now start with J for "joint". It is even beginning to happen in medicine, with the (very) old style of local cottage hospitals of my youth increasingly giving way to a "centres of excellence" approach.

Amortisation through component (code) re-use is a first step in making software development a more predictable, measurable process and in this area CPAN is a great strength of perl. Unfortunately, there are still way to many situations where mixing and matching these components is a little like trying to thread an 1/4" BSF nut on a 3/16" BSW bolt using a 12mm spanner. Each component works well for its designed application, but the 'packing' and 'grease' required to make them come together is still an unmeasurable process. Perl's saving grace is that it is wonderful glue, that used correctly requires sparing application.

How does any of this answer your question? I'm not sure it does, but the trick, if there is one, to cordial and productive client/ coder relationships is a mutual understanding of the problems and a desire to reach amicable solutions, plus some trust. Any such relationship that is based solely upon 'rules and regs', 'tender & contract' or piecework metrics--ie. the need to "prove"--is fraught with problems. If you can persuade your client to truly recognise that, half the battle is won. Then all that's left it to engender trust and write the code:)

Good luck!