How to work in a team where half the devs write logic in code and the other half in stored procedures?

Question

I'm currently working on a team that has half the developers thinking in terms of "objects" and the other half ignore the concepts all together. It's starting to make working together more difficult because the OOP guys (myself included) want to build reusable components that can be leveraged across the system, but the SQL guys just create a new stored procedure at the drop of a hat (or when they think, i need to do this so lets have SQL Server do all the work / all the time)

What makes this increasingly difficult is that my project manager is not technical, and won't step-up to say one way is the "recommended" approach for line of business apps. Yet this same person can't "understand" why the team is having issues getting work done (and not re-writing each others code)

What suggestions do you have for this type of inefficient team dynamic?

Answer 1

If your boss isn't going to be helpful by setting expectations and standards for this kind of thing, you need to come to an agreement with the SQL people. A compromise is abhorrent to most programmers, as we seem to have a keen sense of "correctness", but the enemy you know is better than the enemy you don't.

If you can at least agree on which cases should require stored procedures and which should be done as OOP, and both sides stick to the agreement, you'll at least know how any problem is going to be approached by both sides. It may not always be optimal, but a documented sub-optimal process is better than uncoordinated "code skirmishes" which leave the system in an unknown state.

Answer 2

My first question is: do you think your way is the right way (and why)?

There are often good reasons to use stored procedures. Maybe some of them exist in your situation, maybe not (this isn't clear from your question).

However, I fail to see how this is any different to having half the developers write their code in C and the other half in C++ (or half in main.c and the rest in other files).

I would hope that the stored procedures are under source control as well (?) so you should just go and look at it when you find a call to it in the code.

If your boss won't step up, there are two solutions:

• go see his boss; or
• sort it out with the other parties.

Answer 3

It seems to me you are missing a team leader to guide your development. Managers are not required to be technical savvy, and that should not weight against your manager.

One solution I see to your predicament is to use your OO skills to wrap whatever the SQL guys throw at you so at least you can isolate the SP's as well as possible.

Answer 4

The easy answer is that someone needs to bring some consistency to the project. The project or development manager or the team itself - whoever has say over these things needs to make a choice. Either design is better than none at all or an ad-hoc mixture of both.

Not to be too glib but if you don't have someone willing to step up and make a decision or bring agreement, the project will likely fail. The lack of design coherence is more a symptom of the problem rather than the problem itself.

Take the initiative to get the team together and figure out a system that people can agree on. They may be right. Even if they aren't, you may need to give some ground to get them to agree. But the important thing is to agree on something people can rely on.

Answer 5

Possibly that code review tactic can help.
Where one man trying to explain to team, why he wrote code in this way and not in another way.

Answer 6

There is certainly room for stored procs in OOP. You could make an effort to utilize stored procs effectively in some of your OOP solutions. Perhaps making an effort to try to do things a little more like "the other half" will help to bridge the gap between the two sides, encourage collaboration and get them to try to see how your half is doing things.

Answer 7

Who is leading this project? Do you have an architect? What I hear, from your description, is not enough planning has been done, as there are no patterns for development, or standards, developed.

When you have this form of inconsistency someone has to step up and lead. If there is nobody there, perhaps you should step up yourself. Be careful, however, that you are not becomming a OOP religious zealot.

As for the objects versus sprocs, I am agnostic on that. I think both, to the extreme, are religious concepts. you should definitely favor a pattern, but mixing metaphors is a pattern. If the mix is not breaking patterns, it is not an issue. If it is causing fights, however, it is a problem. The use of patterns, however, is more for maintenance and you can refactor to patterns as well.

Answer 8

It sounds like you need a team leader appointed with the technical knowledge and corporate firepower to know what is right, and implement it by way of enforcing certain standards.

In the meantime, though, the best thing to do is to either play nice or play dirty. Play nice by using existing stored procedures in your code and annotating it to show that the stored procedures were there beforehand (score some brownie points with management with Code Reuse™), or play dirty by rewriting stored procs left right and center, and building the object model so it won't be a pleasure to bring more stored procs into the picture... until they give up.

Answer 9

The problem is that you are not working as a team to come to a consensus.

Yes, a team leader with final say is nice to have in these situations because they give you an easy out; they can just make the decision and the losers have to live with it. But if you don't have that then you must collaboratively work as a team to come up with a consensus. That means actively discussing this stuff until you come to a resolution that everyone can agree with.

Your question makes me wonder what other collaborative problems your team is dealing with. Do you have any coding standards at all? Are some members doing unit testing, but not others? Obviously there's no pair programming going on, or code reviews, or anything that would help you become a better team with shared knowledge.

If I were you I'd try and get a team meeting together to discuss this stuff. And I'd get the manager in there as an observer only; no talking from him. Let him see the difficulty your team has in just trying to come to a consensus on an issue like this.

Others have pointed out that there is room in the OO world for sprocs. Personally, I like to think of that as very limited room. Edge cases. But that doesn't mean no room.

Your team needs to come to a consensus on how you handle sprocs. My suggestion (and only because this is how I prefer my teams to run) is to use good OO design with a capable OR/M at all times unless performance dictates the use of an sproc. And when someone thinks there needs to be an sproc, then I prefer to have the team discuss it, in case someone can come up with a better way. But again, that requires a team that is willing to communicate and share ideas without fear from each other.

Answer 10

What I suggest, and the underlying content of most other comments here is your team needs a standard to follow. Even small shops benefit from a set standard as it keeps code conforming to a set of predetermined concepts.

I worked for the longest time with a guy that would comment everything - while it was good to some degree, it went way beyond being practical. I actually counted the lines of code in one of his routines and it was 80% comments 20% code - and this was for a routine that had a total of about 1000 lines of actual code. It just drove me and the 2 other developers crazy. He also used a different white space scheme that tabbed every 3 characters, while the rest of us used 5. While my situation is slightly different than what you posted, the root issue is similar.

Eventually, we took a weekend and compiled a series of written standards we each agreed to follow. I no longer work at that company but the standard is still used.