A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment “we don’t need a DBA.”
It would be notable if this sentiment wasn’t so widespread – but I see it often. How often? Well, I would have to tell you how I see it to qualify that statement:
You see, people rarely say to me “We don’t need a DBA.” Mostly I see it in their applications – many of them prominent companies in which you may even own stock. I can tell when I examine their schema. I can see it when I execute Profiler against their SQL Server database.
Now, there are lots of reasons to design a denormalized schema. And there are lots of reasons to encapsulate the business rules in code. This is not what I’m talking about – though some of these systems would clearly perform better (or at all, in extreme cases) if they took advantage of better design patterns.
I’m talking about designs where this much is obvious:
1. At least two people designed the data layer; and
2. They did not communicate during the process.
Often, enterprise-level database design is shoveled onto developers as a secondary task. No, I’m not making this up – it’s too tragic to joke about. There are developers who can handle this task. But there are more who believe they are database developers than actually are. (Before I became a SQL Server DBA I was a developer who thought I was a SQL Server DBA…)
There will doubtless be readers who can provide examples of how their enterprise application was built by junior developers who did the database and code work and whose systems are performing just fine. I’m happy for you and sincerely hope the system scales.
Designing a scalable solution – database, application, or enterprise architecture – is one of those things that consumes time, thinking, resources, and money during the early phases of an enterprise development cycle. But it is – hands down – one of the best investments (if not the best) in the solution.
In today’s market, scalability is as optional as security. And like security, a scalable design is not something you “add later.” It’s not part of the foundation – it is the foundation.
My experiences with designing scalable solutions has proven there is no free lunch nor any shortcuts that work. If anyone – me included – skips the work of designing for scalability, there comes a day when they (or I) must pay the fiddler. From what I hear and have experienced, designing in this fashion is most often sacrificed on the altar of the deadline. Trust me, if it falls apart in six weeks or six months, you haven’t saved any time – and you may have lost a job or a customer.
Someone told me this and I remember because it has proven true several times over: “Deliver quality late, no one remembers. Deliver junk on time, no one forgets.“
If you’re building (or upgrading to) cutting edge technology, you need a DBA.
:{> Andy
Technorati Tags: Software Business scalable database design quality
Amen!
I thought this problem only existed in Belgium.
If everyone hired competent DBAs, we (consultants) would be out of the job 😉
>>If everyone hired competent DBAs, we (consultants) would be out of the job 😉
In that case you would be working as a full time employee instead of a consultant 😉
Wouldn’t that mean that I’d have to be a competent DBA?
>>Wouldn’t that mean that I’d have to be a competent DBA?
You probably need to be a hybrid DBA
A DBA/DB Developer will become the Prius of computer programmers
you need to know:
Administration
DB Design
T-SQL
SSIS
SSAS
SSRS
SQLCLR
…..
…
..
Yes you are more expensive than just a DBA or just a developer but the company will getter mileage out of you, just like comparing a prius with a VW Jetta (Bora for those in Europe). A Prius is more expensive but gets better mileage (Jetta TDI doesn’t count)
Denis
I want to be the Humvee of computer programmers… Burn lots and lots of fuel, but can take a few bullets, ride over rough terrain, and go where others can’t, when necessary <g>
Are you saying you want to be Agile?
Hmm, is a Humvee really agile? Agile sounds to me like one of those water/land vehicles 🙂
I agree with the need for a hybrid, but I’m from the software programming side and would so classify it as a hybrid programmer, with solid programming skills AND DB development skills (but including tuning/troubleshooting/maybe SSIS). Where I have in the past grumbled is when I have to venture far into what I consider "DBA territory"… which brings me to a recent story:
A few months back I was looking for a new job, and interviewed for one looking for a ".NET/SQL Server Programmer". Interviewing went well, but it was obvious to the interviewers that my skills were more heavy on the development side (but solid for .NET as well as SQL Server), but it turns out they were looking for someone with very thorough DBA skills! If it wasn’t clear, I didn’t get the offer but about a month later, I saw in a posting to the local Richmond SQL Server UG a guy they did end up hiring looking for anyone to provide guidance on getting .NET experience, because he had none but really needed it 🙂
Where I now work at, it kind of is a mix with only a few programmers and a DBA. We all work together including the database side of development… we are kind-of all becoming hybrids together I guess.
Personally I’d like to see the titles "database developer", "DBA", "Production DBA", etc., go away entirely. I like just "database professional" that specializes in certain areas. There are just way too many things that "hook" into a database to isolate that knowledge into a single job role. I’d love to see us all understand a portion of what the other does, a sort of cascading overlap in job descriptions/responsibilities.
Unfortunately, I think it unlikely to change any time soon. Sigh…
K. Brian Kelley – Andy blogs at SQLblog.com (not SQLblogS.com – a defunct site)