Should software developer charge for Specs Gathering Time?

As a software developer who charge on per hour basis, should one charge on the specification and requirement understanding/gathering time? And what about the time for testing and debugging?

I believe that what makes programming so hard is not programming itself per se, but the understanding of the domain ( such as the mechanism of put call option) or the whim of the business owners. Requirement gathering can take up a lot of time, particularly when the domain is exceptionally hard or when the business owners themselves aren't sure of what they are doing.

But is it right for the developers to charge for the time taken to understand the requirements? On one hand you can argue that the developers shouldn't because it's their own fault not being able to understand the thing, on the other, you can argue that the developers should because time is money. Not to mention that without charging for requirement gathering might have a potential disastrous consequence on the financial well-being of the consultant.

What's your take?

YES YES YES YES YES YES YES YES YES !!!! Holy crap YES! Yes, you want to charge for requirements gathering and specification writing!

This is the most important part of the whole development process!

Here are some tips for maintaining a good relationship with the client during this process :

1. Charge hourly (because the customer can drag this on forever)
2. Do all work in their offices.
3. Merge all of your thoughts and notes into a nicely formatted document and email it to the client at the end of every billable session along with the number of chargeable hours it took. (turn on change tracking if available to really emphasize the changes made)
4. If the client doesn't value this part of the process enough to pay for it, that's a really good indication you should walk away from the project.

However, requirements gathering and an initial consultation is not the same thing. The initial consultation is your sales call and you can't charge for it without killing the relationship. What you might want to do in this case is dedicate up to N hours as part of your free consultation (1-4 I'd say).

Let me add a few more YES's to John's answer. YES, YES, YES!

Requirements gathering is a good 1/3 of the initial development, and maintenance can represent 80% of the lifetime costs. If you don't charge for these items, then you will either go broke or provide a terrible service.

The challenge is to explain to your clients how software development works, and have them understand why they're not just paying you to hammer code.

I agree with John MacIntyre. I like the comment about doing the work in their office when possible. The "visibility" they perceive helps to build the relationship.
I have been in situations where we didn't charge, and the customer milked it for all it was worth. This seemed especially true of larger companies which seem to expect "free" time when they can get it.

I ran a small software consultancy for four years and we always charged for the initial design / planning phase as well as the final testing / bug fixing phase.

Our estimations would involve these and I have not had any client debate or argue on these points.

Designing the system, requirement gathering, etc. are all part of the software-building process and it should definitely be billed for.

As for the testing phase, if you write code, there are going to be bugs in it - and on an average 1/6th - 1/8th of the total cost of the project would be for testing. Requirements gathering would again be 1/6th - 1/8th depending on the scope of the project.

I cannot agree more with John MacIntyre - that if a client does not agree to pay this, you should definitely walk away from the project - because this is only going to cause a LOT of heartache later on and you will soon realise that projects with such clients are generally a loss making enterprise.