Another thing I am seeing more of that requires some comment is poor requirements definition and specs for technical work.

An obvious benefit of a development team working to correct and complete specs is the output can be measured against the spec to give the project a logical and objective conclusion.

The other side of this is a healthy spec & requirements sesssion incourages the stakeholders in the project to actually think through their requirements.  Lesson: Don't take this for granted.

I've just seen a couple of notable examples of this lately when questioning a minor point in the spec has had the client say "Ah!  I didn't think about that!" raising more fundamental questions about the project.

I'm working on a throey that you can never ask the average guy what they want, because by virtue of being in the middle of their own business domain they are blinded to actually knowning the right answer.  You can only learn what they need.

After blog mint [?]:  Just more on that "ah!" moment.  I'm not saying it's a failing on the stakeholder's part.  It's natural and healthy part of requirements definition.  Just don't forget that it can (and will) happen.

I know what makes me sick and what makes me well, but that dosen't make me a doctor.

Knowledge of a specific business domain dosen't qualify you through some holy invocation to be a database designer.

Sounds like I'm taking a pretty hard line on this :)

Really it all stems from seeing people put in way too much effort to cope with bad ideas.  Take for example this pretty simple rule of normalization:

• Every time a row and column meet, that cell should hold one and only one bit of data.

Break that rule and you will be forever doomed to write hard to maintain queries.  I was just discussing a scenario that needed to  regularly update part of a field for a large number of rows.  Luckily that scenario isn't seeing the light of day <phew>

So, what criteria do you think should be on the test that issues licenses to develop databases?