First of all, by functional tests I understand tests of application features primarily from user (UI) perspective, with different set of frameworks - Seleminum, Watin, FuncUnit or whatever.

I’ve seen the cases that functional tests are being implemented either first or immediately after some particular feature is implemented. I think this is a just wrong practice. Even the UI testing could definitely provide value you should think twice before getting to deep with functional testing and apply as development process rule. Functional tests have several serious drawbacks:

• Fragility. Functional tests are extremely fragile. You could run test suite and got green results and re-run them in 5 seconds and got completely red sheet. And there could be thousands of reasons why it happened.
• Speed. They are simply slow. As much tests you have as slow they are. As much slow tests you have as long feedback cycle is. As long feedback cycle is as low value you are getting from tests.
• Bad isolation. Because of functional tests have integration nature, it is just not possible to run them in isolated environment. Tests became depended from each other, that in particular leads to fragility.
• Support. Implementation of UI test is not trivial thing. Even with so cool frameworks like FuncUnit or WebDrivers that have strict and clear interface, it could be hard to test some UI feature of application. But support is much more harder - really small change in could turn many tests to red state. In fact, implementation of change that costs you 1 hour, could cost 1 day for correction of tests.
• Changes. We are trying to adopt agile into development world, one of the aspect that makes development really agile is reacting on change. Reacting on change have to be fast. Changes are integral part of development, even if developers hate changes. But as I said above, even small change could ruin UI tests and it is not fast to fix it. It means that cost of change is getting more and more expensive.

So, trying to implement UI tests in early development stages or cover all applications features with UI tests is a waste. Ratio between effort / value would be just go to zero with time.

What I think as recommendation for UI testing:

• Rely more on unit tests - all server side code must be covered with a different level of testing. Units have to be isolated and fast.
• Keep view as thin as possible - in ideal you should not have logic in view at all, but modern web application heavily using client side (javascript) logic that affects view. Javascript code have to be unit tested with qUnit or similar frameworks.
• Don’t start with UI tests - UI testing have to be done last. If the feature is just implemented it does not mean it has to be immediately tested. It has to pass PO approval, QA. Ideally it has to be released to beta group and confirmed that “this is exactly what we need”. After feature stabilized test could be added.
• Don’t try to test everything - since UI testing cost more, you should be more careful. It has sense to automate smoke test, critical parts of application or parts that have high regression.
• Clean up tests regularly - peer tests regularly, if you have bunch of tests for some area that works OK for a long time you might consider to remove those tests, to speedup whole tests process.

Keeping focus only of primary features of application and avoid of testing small stuff should be key for functional tests.