Currently my shop is making a switch from the usual ".NET/TSQL/XHTML+CSS" Jack of all trades developer to a more focused shop where the app dev only works on pushing the business requirements into code, the SQL dev only writes stored procedures and SSIS packages/etc
Is this best for everyone or just big enterprise shops where everything needs to be segregated for the usual political reasons?
Sounds like a good way to make your app developers grow rusty on their database skills to me.
If you depend on one person for everything, you'll have problems when/if he leaves...
I'm all for multi-disciplinary teams
As with anything in our industry, "your mileage may vary." In most of my dealings, there is a separate SQL developer who is decently versed in development, decently versed in DBA activities but a guru in data design.
I like that approach, but I believe individual, non SQL developers should know good data design and be able to translate their requirements into a decent model and be able to talk about terms like normalization, foreign key, indexes, etc.
It's dangerous to put too much separation between database development and the rest of the code. Developers need to understand exactly what's happening to the database, and the database guys need to have a good handle on the rest of the application so they know what to expect.
It's good to go with generalists while the team is small (1-5), and then start getting specialists after that, but don't ever let the barriers between the groups get too thick.
This will create a bottleneck and in some cases a deadlock where the programmer thought the database guru was doing it and the database guru was waiting on something from the programmer. Although it is good to have some specialists on staff, for day to day development a jack-of-all-trades is preferable. Keep the DB specialists in reserve for optimization duty and DB administration tasks.
That's a natural progression as the team gets bigger. When you have a small team of only 2 or 3 people you need everybody to be able to contribute to all parts of the application. As more people are added you can afford to have some specialization, with some people working on the GUI, some on the database, some doing systems analysis, etc.
It can add overhead having a dedicated database person because suddenly every new query or change to a query has to go through them, but it can also be beneficial because they'll have more expertise in the area and could produce higher quality or more consistent work in their domain of expertise.
I agree that we aspire to have multi-disciplinary teams but we still like to have people who become "ninjas" of certain technologies.
The tools and techniques for individual areas of development are becoming far too broad for everyone to stay on top of and to monitor related blogs, Service Packs, etc.
So its a hybrid system which seems to work well where we strive for everyone knowing what they need to know and some people who have obvious talents in very specific areas becoming subject matter experts for the group's benefit.
Thats what seems to work for us in a shop of 30 developers or so.
Big enterprise shops that segregate disciplines can do so because they also have project managers, architects, technical writers and semantics officers who all learn multiple disciplines, then design systems with good Separation of Concerns built-in.
All that comes at a cost, though. Smaller shops are better with Jacks than with Einsteins because the HR overhead is much lower.
I have seen "SQL Developer" role specialization work when you have someone coming into software development from tech support or from a business role (billing, etc.). It lets them focus on a stable, fairly consistent syntax that is relatively intuitive, and they can provide value to the team fairly quickly.
As a career path, though, I think it would definitely limit you to "big enterprise" IT jobs if you could only do DB development.
I can tell you that we use both where I work. Each developer writes their own queries for use within the framework but we also have a DBA. The DBA's job is to implement the database changes and provide optimization advice where needed. We can shoot off an email to have him look at a query for ways to optimize or better write it, but in general we are encouraged to do it ourselves. On rare occasions, when resources are exhausted, we are able call on an outside resource.
All in all though, if a developer cannot write basic to intermediate SQL you're likely to have larger problems down the road.
The big problem with discipline specific resources is keeping them busy, There is also a perspective multi-skilled developers can share that is very benificial.