I have to totally disagree with the following from the article:
Database development has a subtle difference from application-development. It is not as easy to fake your completion dates, i.e. using technical debt (a.k.a. dirty hacks) to meet a deadline and then quietly filling in the gaps later. In a database, this is a sure route to invalid data, missed orders and unhappy customers.
Technical debt in application code is usually permanent. Or at the very least long term. In my experience more systems with databases have DBAs that are allowed to alter the database along the way than application support developers who are allowed to change a single line of code which isn't related to a specific defect. There is no "quietly filling in the gaps later".
Also there are temporary shortcuts that could be done in a database that can be backfilled by production DBAs without adversely affecting data. A particular example I have seen is the delayed delivery of a datawarehouse database with reports temporarily (inefficiently) produced from a duplicate (often restored backup) read only version of the production database.
As for empathy with PMs, it is good to have it but it must be tempered when they say that a "deadline has been forced on them" as it is their responsibility to highlight when such deadlines are not achievable whilst maintaining a satisfactory level of quality.
I must say that I lean towards Jeff's point of view although I totally agree with Marcia too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!