June 28, 2008 at 8:02 pm
There are several technical roles involved in building and maintaining database-driven business applications. Three roles are mentioned here: application developers, database developers, and production DBAs. An application developer is concerned about the code accessing the database. A database developer is concerned about what's happening inside the database. A production DBA is concerned about the server environment for the database.
A quick check of available positions on popular job boards reveals a gap, or a missing link. Companies are seeking application developers, requiring specific language skills and secondary database/SQL skills. Companies are seeking production DBAs, requiring a wide variety of server-level skills. Companies are not seeking database developers to link the other two roles. Instead, companies hire teams of application developers and let each member contribute to database development using his/her own style, and then they hire teams of production DBAs to resolve performance issues by adding and managing server hardware.
It would seem more sensible to have database developers guiding and coordinating database development. The databases would be much more robust and efficient, so there would be less need for server hardware. The application developers could focus on their strengths and the production DBAs would have fewer problems to solve. Alas, businesses are hurting themselves by having nobody take ownership of database design matters.
I have seen business databases with severe design problems, such as poor normalization, missing DRI, and massive inconsistency. The databases were built on an impromptu basis by application developers working outside their area of expertise. The databases are constantly plagued by performance issues and data integrity troubles. The companies are trying to resolve the performance issues with server hardware and production DBAs.
I would like to start a discussion here to learn about the observations of other database professionals. Do you think this kind of situation is common?
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
June 28, 2008 at 9:32 pm
Very true. And sadly not even Microsoft is immune to this as some of thier most important flagship products show clear signs that their databases were designed and implemented by application developers and NOT database professionals.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
June 28, 2008 at 11:27 pm
In an attempt to avoid being flamed, please allow me to clarify one point. The application developers out there are just as "professional" as the database developers or the production DBAs. Nothing in this topic should be construed to mean otherwise. The three roles do different kinds of work and they need different sets of skills. There are varying levels of proficiency among the members of each group.
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
June 29, 2008 at 10:19 am
I think this is generally the case, though I do see some database developer positions at times and there are plenty of DBAs that do database development work and don't do administrative/production work.
The big issue, IMHO, is that most developers learn to work the front and, they learn procedural and OOP techniques, and SQL isn't a part of this. Thinking in sets is hard, especially when you spend lots of time building things that work with objects or singular pieces of data.
So they don't learn, or don't learn much. that's a gross generalization, and I've met some talented app developers that knew SQL very well. However it's been few, with most developers being unskilled or poorly skilled at SQL and not really wanting to learn.
June 29, 2008 at 12:58 pm
Wingenious (6/28/2008)
It would seem more sensible to have database developers guiding and coordinating database development....
The databases were built on an impromptu basis by application developers working outside their area of expertise. The databases are constantly plagued by performance issues and data integrity troubles. The companies are trying to resolve the performance issues with server hardware and production DBAs.
AMEN!!!! And, no... you don't really want me to respond any more than that because it absolutely will become a flame war. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2008 at 2:32 pm
I have been watching the job boards for positions mentioning SQL Server for about five months. In my area (Twin Cities), about 40% of the jobs are application developer positions requiring secondary database/SQL skills, about 30% of the jobs are typical database administration positions, and about 30% of the jobs are positions with a primary requirement of SSIS, SSRS, or SSAS experience. There has been almost nothing asking for data modeling and database design experience. I suppose one could say SSIS, SSRS, or SSAS work is database development, but it's not the kind of database development I'm referring to here.
I'm sure there are application developers who are quite capable of doing database development. If you have a team of five such people they will do things at least five different ways, leading to chaotic inconsistency in the database design. I have seen it happen, even when "Best Practices" and code review processes are in place. I believe the only way to avoid the problems is to have somebody take ownership of database design matters and ensure things are done completely, correctly, and consistently. It appears that companies/employers do not share the same opinion and I think it will hurt their business over time.
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
June 29, 2008 at 3:03 pm
I agree.
Its a matter of the way we do things.
As an App developer we often focus on singular objects or instances.
But as database developers we focus on not one object but relationships, referencing and bulk datasets - whether the set has one member or a million doesnt matter - handle the whole set.
Someone once said to me - You guys just think of things (in the app) differently.
June 29, 2008 at 5:26 pm
john.henderson (6/29/2008)
whether the set has one member or a million doesnt matter - handle the whole set.
That's step 1 to perfect set based thinking... glad to see someone else believe in such a thing. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2008 at 6:19 am
I've found that the better application developers tend not to think in terms of single objects but rather in terms of collections. Obviously a collection can have zero or more items.
June 30, 2008 at 8:28 am
Every time I interview I get asked if I consider myself more of an application developer or a database developer and I have to always answer "both". I use a "separate but equal" theology when it comes to my database vs application development. I do the database design and development first, it usually ends up at about 80-90% complete before I even touch the application code (then it ends up getting tweaked over time as I find other things it needs to do..but the overall schema usually doesn't change too much) because the database needs to provide a solid foundation for the application. But, I usually am working on very small teams (1-4) and I'm usually the one calling the technical shots.
No one seems to believe that a person can put equal attention to both the DB and the application but such is life. There's always such a desire to compartmentalize people, sometimes it makes sense and sometimes it doesn't.
Whether you should have dedicated DB developers vs. app developers probably depends on your company size. If you only have one developer,shell out the extra money to find someone who is competent in both. If you have 5+ developers you probably could pop for one or two who specializes in database development but then prepare for at least a little time inefficiency in having to split the tier development. (I know I would be annoyed if I had to wait for someone else to write my stored procs for me, but then again I think I'm quite proficient at it...I'd rather have my junior devs have to wait for a competent database developer and lose a little time than write crappy inefficient procedures). In very large teams it usually makes sense to have dedicated personnel in multiple tiers (and that also goes for splitting app dev into business logic and UI, but that's another topic).
--
Anye Mercy
"Service Unavailable is not an Error" -- John, ENOM support
"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya in "Princess Bride"
"Civilization exists by geologic consent, subject to change without notice." -- Will Durant
June 30, 2008 at 11:15 am
The OP's observation rings true in many of the job markets I keep my eye on.
I also agree with many of the follow-up posters that set-based thinking is a different mindset than is typical for an application developer, but I don't necessarilly think that it's where a db developer's strongest value proposition lies.
I think the main value that (good) db devs bring to the table is the ability to more efficiently iterate to a rationalized model of the information in the system. This follows from the simple fact that we deal with constructs at a higher level of abstraction than application developers do, and are therefore more free to iterate over different designs, testing each as we go along. Application developers are working at a lower level of abstraction, and, despite the plethora of tools to enable refactoring, etc., simply cannot iterate over their designs as quickly. I also think a strong modeler will be able to properly weigh the tradeoffs and produce a first-cut model that is much closer to the "best" design.
It is rare to find a company that understands the value of a db developer, and that understands how that value can be leveraged to help the application developers, so if you're in the market and you find such an opportunity, go after it aggressively!:cool:
TroyK
July 1, 2008 at 8:48 am
[Old fart alert]
In the [good] old days, I used to describe my self as a "sytagramerator" (systems analyst, programmer, operator). I would, perhaps, need a much longer buzz word nowadays to include OO, Relational, DBA, diagnosis, and web stuff I wind up doing.
But I think there remains a danger in the level of specialization that the growth of technology has spawned. There is something to be said for having a single mind that understands the problem to be solved. In fact, I have found that the most valuable technical staff members are often those with the broadest, rather than the most specialized skills. A good professional ought to be able to research and learn what s/he needs to know to at the detail level to get the job done.
The very real danger is those who don't know that they don't know, are unwilling to learn, and are willing to fake it!
[/Old fart alert]
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply