It's not about how fast you code the requirements but how soon you get them right

The actual software is just a byproduct of the process of building an understanding of a given domain.
Jonas Bandi

The misconception behind the RAD tools comes from the desire to implement the software (ie. do the coding) as quickly as possible. People believe that producing software is hard - and they're correct, it really is! The problem is that it is not the implementation that is tough. Meeting blurry, vague wishes of your client - sometimes erroneously called requirements - is the hardest part in software development. And unless you work on really dumb system for feeding the data using few hundreds of forms (which most probably means you do software for govmt) you really need to get the domain right.

On all projects with non-trivial business domain you spend most of the time analyzing clients requirements, evolving (expanding and refactoring) the domain model to meet your clients demands. You spend hours in front of the whiteboard with the marker in your hand talking about the domain. You do Proof-of-Concept, you revert, do it again, revert.. And then if you're totally, 100% sure what's really going on in this damn business domain (and BTW most probably you're still wrong about it ;)) you go to do some front-end, mailing, logging and all that supportive stuff.

In my first job I had a teammate who was a decent programmer but he shone big time. I spent a gigantic amount of time on learning every detail in technology we used and I knew the class model very good. He knew just enough about it but still when it came to talking about the project he always knew better. The thing was it that he focused on and understanding specifics of business domain what almost always gave him massive advantage.

Most of the time you do the knowledge crunching.