I really don’t like to rant and express my opinion on my blog as it often leads to debates that generate sides and entrenched ideas. That only leads to bad things. I feel a level of frustration, at the moment, that I felt I needed to express. This post is simply that, an emotional response to a seemingly common and frustrating problem in our industry, not meant to generate any real debate, just a rant.
In attending the session, BI, SQL Server 2005, and Hockey, Eh?, on SQL Server 2005 and the capabilities of Reporting Services at the Calgary Code Camp, I came to the realization that the role of the DBA has definitely changed. Let’s face it, anyone can create tables, stored procedures, triggers, users, roles, indexes, blah blah blah (Note: I didn’t say "create well", just "create"). If that is all you or the company you work for is doing, you likely don’t have a need for a DBA, developers can likely fill the niche for you. The caveat to that is that if you want to do ANYTHING else (database maintenance, monitoring/performance tuning, database specific development like business intelligence units) you will quickly find yourself be dead in the water.
Barry Hensch‘s presentation was evidence of that. He got into building OLAP cubes, using reporting services, cautioning against naming things a certain way; all things that, unless you have previous experience doing them, you are definitely going to mess up. The body of knowledge a database SME carries with them is invaluable. You can’t just learn it as you go along, not at the pace that businessed want to move at.
In talking with Barry after his session I made mention of this. He agreed and stated that the same goes in reverse, that developers of a company’s software factory require the types of specialized training that a company just wouldn’t achieve full value if they attempted to cross train their development staff.
If you are a company serious about stepping up to the big time and want things to be done right, you just HAVE to get the right person for the job. Don’t get your .NET developers to manage database stuff, let there be an interface between the database guys and the software factory guys (often being stored procedures). Let them each focus on what they are skilled in doing and you will reap the best benefit for your dollar, even though this expertise does not come cheap. The question you have to ask yourself is, "Do I want to pay the money to have this built right, or would I rather it take longer, possibly never get finished, and have higher maintenance costs?". Unfortunately finances often dictate the latter and a company’s project fails or limps along forever.
You simply don’t want your Ferrari (feel free to transpose your favorite high-performance, luxury vehicle name here) built by shade-tree mechanics. That’s also why you don’t see Ferrari’s at your neighborhood fix-it shop. Ferrari’s are high performance, they are built with quality, and they don’t come cheap. I’d bet that their owners don’t talk to you about the price because they feel they got their every penny’s worth of value after the purchase and, let’s face it, everyone can appreciate that it’s a Ferrari. Even if you don’t like the look of them, you can appreciate that it is no Sunfire.
If you are in a situation where your company can’t afford to build a Ferrari, face reality, you’re not going to build a Ferrari; period. You can’t replace a Ferrari mechanic with a larger number of shade-tre mechanics and expect a Ferrari to come out of it. Similarly, you can’t replace senior developers with a larger number of inexperienced developers. It doesn’t work that way. Inexperienced becomes experienced/senior through only one mechanism; experience, which costs time and a lot of mistakes during the learning curve. You just can’t circumvent that process. So, hire the right people for the right job or realize the limitations of the potential the assets of your company have and use them to the best of your advantage. When upper-management wants to start pushing out Ferraris, have them open up their pocketbooks and get Ferarri mechanics in there to do the job.
As a slight aside, if a shade-tree mechanic wants to become a Ferrari mechanic, they can do it. They need ambition, drive, mentoring, and experience. An inexperienced developer is no different. They can remain the same inexperienced developer if they don’t have the drive to excel as a developer. Years of experience don’t necessarily equate one-to-one. We can all tell the difference between a Ferrari mechanic and shade-tree. Similarly, we can tell the difference between inexperienced and experienced developers. You can’t force experience on someone, they have to have it in them to propel themselves forward and improve. Most of us need shade-tree mechanics; we don’t all drive Ferarri’s, but we got what we paid for and we are comfortable with those limitations. We don’t expect a shade-tree mechanic to do anything but be able to built/repair our Sunfire.
I don’t know; maybe the point of all of this is that we just need a better mechanism for managing expectations. Get software factory developers to do software factory development, get database developers to do database stuff, have inexperienced people get experience from the experienced ones as they build the product.