Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Our T-SQL developer just gave his two weeks notice. We have been asked if our team of four developers would like an additional developer.
We are offered to do our own T-SQL / Entitiy Framework development or we could get another dedicated T-SQL developer.
What are the pros and cons with having a dedicated T-SQL developer on the team?
Which would you prefer and why?
If you have at least one person on your team already who can:
You might already have another t-sql developer who can keep the team at least in line. My list isn't comprehensive but if those things are there he can probably keep you guys out of trouble.
If you don't have someone on your team who can do those things and your team does have their hands in the database, you need someone who can do those things. Unless you're completely unconcerned with the quality of the database (a valid stance if the system is tiny enough, read: under 15 tables perhaps.)
What sort of application are you working on? Since you've had a database/T-SQL developer on your team previously, I assume that it's reasonably database-centric, but the answer to how the database is actually used by your application has an impact on whether a separate database developer is needed or helpful.
My initial reaction was "you want a T-SQL developer with database development experience on your team", but if the database is little more than a data store (little or no logic in the database layer), then perhaps you could make do without. Same if the database design is simple (meaning that to extract something useful you don't need umpteen million joins across dozens of tables), or if performance and scalability aren't great concerns in your case.
An obvious drawback of a separate database developer is the short-term cost of another developer who won't be contributing directly to the user-visible portions of the software.
Assuming that the application you are working on is reasonably database-centric, once the initial ramp-up period is taken care of, having a developer who can focus on the database aspects of the application can help quite a bit. You get someone who knows the ins and outs of set-based programming, can focus on what amount of data normalization in storage is useful in your particular case, and can hopefully help come up with or further the design of the database to provide good performance now and in the future.
Having an application developer also do database development doesn't necessarily have to be a bad thing, but there is an obvious risk that the developer in question will focus more on the needs on the application side than on what makes a good, scalable database design and then figure out how to expose that to the application layer in a way that provides the application with the data that it needs. This can lead to short-term results and long-term pain when the underlying design turns out to not be scalable. Of course it doesn't have to happen that way, but it's a risk well worth being aware of.
As for communications overhead (and particularly that causing delays), it doesn't have to happen that way. If the other developers on the team know a bit of T-SQL (it's not that hard picking up the basics like how to do selects, updates, joins, etc.), then they can certainly do prototyping in the database layer just to get the data that they need. Before the code goes to production (whatever that means in your environment), the database developer can either sign off on it saying that it's a good enough design, or take the input parameters, desired result and output result set design, and figure out a better way to perform the actual queries.
Pros:
Cons:
I think you can figure out where I am going with this.
You need a DBA. These are people who take care that databases are running, running well and to requirements. People who will educate and teach the developers as to best practices and what to avoid.
If you don't get a dedicated DBA, one (or all) of you will have to take up the slack, working on things that are not directly development related.
Though my points are about DBAs (as that's what the title of the question was originally), except for the backups and maintenance points, the rest are valid for a T-SQL developer.
The assumption is that a T-SQL developer is a professional that understands how that database works and best practices etc...
If you use EF and don't have someone who understands how a database works, you can be in problems. If your team is proficient (understands indexing for example and when to apply them appropriately, understands how to optimize a query etc...) then you probably don't need a dedicated T-SQL developer.
Which would you prefer and why?
It depends on my team skillset and the application. If the team has some SQL background, then they can make do. If the application doesn't have enough SQL work to keep 1 guy busy, then I maybe don't want a dedicated guy. If the SQL work is basic CRUD stuff, then I don't need a specialist for that.
And the opposites are true. If the team is SQL ignorant, or the app is SQL heavy, or the SQL is complex then maybe a specialist is the right way to go.
It's just like any other skillset on the team.
I think that having a dedicated t-sql person on a team that does EF is a luxury, unless her or him also helps out with the .NET side of the project. Most developers in micro-sized teams, such as yours, should be familiar with enough SQL design and tuning principles to bring your project to acceptable levels of performance. The problems that your four developers cannot address should be solvable through Stack Overflow and short-term consultants.
Short Answer: It will depend on the scope of the project and developers skill set.
For example: a Database First approach with EF may need a good T-SQL developer. Because a solid DB design with, indexes, stored procedures and functions might be very useful for targeted performance boost areas within application.
For a code first approach without any usage of complex stored procedures you may probably have NO need for a T-SQL developer.
In addition, if you have in your team a developer who has solid knowledge in DB design, index, query profiling, analysis of execution plan... then you have a right guy in a team to take care of all DB development that you may expect to have.
Short Answer:
That depends on the scope of the project and developers skill set.
Long Answer :
While acquiring such T-SQL or DBA specialists, you and your colleagues have to be trained up in the sense that they must have the mindsets and methodology to handle the SQL
It is because as the development grows for a long time, your SQL and exception-handling cases must increases and be more complicated.
