|
No doubt there's a potential for abuse, and there's middle grounds to be had. I've also caught hell from a PM for a project being 'late', even though I had 0 control over actually getting DB changes in, because the DBA was a) on vacation, then B) sick, then C) backed up on other work. But apparently, it was my team's fault that the project relying on a SQL database was not launched "on time" (a deadline I had no hand in making, nor did I agree to either). The policy of "only DBA can make any changes to anything, and all schema changes have to be discussed, reviewed, vetted and approved by DBA" has benefits, in some situations, but also problems. I had a DBA question why I needed pagination. "No one has ever asked for it before, and never needed it, and I think you're building your application wrong if you need that". After a few weeks of contentious meetings, we got hand-rolled stored procedures for each specific table/query, but they also took days to get to us. But, hey, you know... at least the tables were normalized and we had "proper" indexes. We just took weeks to get done what should have taken a few hours to prototype (because, during the time we were building the tool, the team we were building it for ended up buying some third party service because we were taking so long). We've all got war stories of incompetence on all sides (dba, dev, pm, whatever). This is why I advocate "middle ground". I trust a DBA who's actually done a bit of raw coding in their life. I trust a developer who understands the basics of SQL and DB workings (again, 'basics' are fine). I trust the estimates of a PM who is engaged with the team on a regular basis. I trust the views of a business analyst more if they actually show up to meetings and listen to the parties involved. |