For the past couple of weeks I’ve been asked multiple times the same question I though I’ve answered a long time ago: Hettie, why do you want to have a database developer on each quad? Won’t it be better, if you just have a team of database developers, and if there is a need in the database work, you would dispatch a developer to a project?

I was so sure I’ve written about it already, but I’ve just looked over all the “people” tags and didn’t find anything… so I guess, I just always meant to write about it, and never did :).

In short: if a squad does not have a database developer, it becomes much more difficult for the squad members to realize they actually need some database work. Since the database is “a backend of backend”, many potential problems which can occur are not recognized as “db problems” or “db tasks”.

On the other hand, when a database developer is indeed a member of the squad, when he or she is present starting from the very first design sessions, when (s)he understands the project/product needs, the better solutions can be introduced from the very beginning, potential problems could be resolved before they occur.

It’s very rarely that “an outsider”, “a consultant”, which a database developer can become if (s)he won’t be a squad member, can grasp all small details about project. I personally do not believe in “theoretically correct solution”. In the overwhelming majority of cases the solution should be tailored for a particular case. The foreign keys and other constraints and functional dependencies are originated in the real world, not in the database. Not always, but in most cases you can’t just look at the database schema and say, whether it is “right” or “wrong”. And that’s where a database developer on a team matters – to do things right. Right away.