SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Software Teams


Software Teams

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)

Group: Administrators
Points: 81635 Visits: 19210
Comments posted to this topic are about the item Software Teams

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
majorbloodnock
majorbloodnock
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1761 Visits: 3062
Good topic, Steve

The thing that springs to mind for me, though, is that trust isn't a binary thing. So often we'll hear someone being told that they should trust so-and-so. In practice, what should be happening is that the person should be learning in which ways they can trust so-and-so.

I work with someone who, because of their organisational skills, can be trusted to manage a project VERY well. However, there's a significant gap between how advanced they believe their technical skills to be, how advanced everyone else believes them to be and how advanced they actually are. For that reason I don't believe them to be worthy of trust in certain areas.

Some of those areas can be changed by my (and other people) spending time passing on knowledge. Some are beyond that person's comprehension. Net result is that I trust that person implicitly with some things and not with others. That person values the former and respects the latter, ending up with a good working relationship but relatively little exposure.

Basically, I believe it is foolish to trust too little but also foolhardy to trust too much. And you can only find a good balance if you're already inclined towards co-operation, and therefore prepared to put in the effort.

Semper in excretia, sumus solum profundum variat
Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)SSC Guru (54K reputation)

Group: General Forum Members
Points: 54648 Visits: 32776
Great comments. That is one of the most difficult problems we encounter working with development teams. They don't trust us and we certainly don't trust them. It takes a while to build the trust. Unfortunately, once built, it only takes a moment to destroy it. Then you're back to the hard work of rebuilding it again. I'm not throwing rocks at developers on this. Both sides have issues. What's worse, it shouldn't be two sides. We have a common goal and we work for a common employer.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Rudyx - the Doctor
Rudyx - the Doctor
SSCertifiable
SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)

Group: General Forum Members
Points: 6075 Visits: 2503
An interesting topic. I do have some major issues though. Trust is something that should not even be described in this context for few very simple reasons. Professionalism, responsibility and if you are lucky, process and procedures. So even talking about 'how much' you can trust someone seems irrelevant.

Now I am ready to weather the storm of comments ...

Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Steve Jones
Steve Jones
SSC Guru
SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)SSC Guru (81K reputation)

Group: Administrators
Points: 81635 Visits: 19210
Rudy,

Have to disagree with you there. I think trust is important because it comes from someone being professional in their job. Process and procedures are the same way. There are people I can "trust," meaning count on, to get something done. There are others that can do the work, but I'd need to remind them, follow up, etc. They are "professional", but perhaps don't give my needs the same attention as others.

There are people that might think they can short cut a step in procedures and process. I can't trust them to do everything they should. Perhaps that means they aren't professional about things, but it also means I can't trust they'll get the work done.

I think trust is the outcome of someone being a professional.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
majorbloodnock
majorbloodnock
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1761 Visits: 3062
I know what you mean, Rudy, and agree with the theory.

However, procedures only take into account a job role, not the present incumbent. I don't know about your company, but every one I've worked in has taken on people who're weak in one area of their responsibilities, seeing that as an acceptable cost for gaining their (excellent) skills in other areas.

If I ignore the fact that they have weaknesses as well as strengths just because the procedures say something's their responsibility not mine, I'd say I'm being blinkered to the likely detriment of the business.

If I recognise they have weaknesses and so shoulder those responsibilities myself, I'd say I'm a candidate for having "mug" tattooed on my forehead.

If I recognise they have weaknesses and so provide a helping hand for them, i'd say I'm limiting my trust, but laying the foundations for greater trust in the future.

And that's just when dealing with peers, so has nowt to do with management. None of that can ever be formalised in processes and procedures.

Semper in excretia, sumus solum profundum variat
Nate Pink
Nate Pink
SSC-Enthusiastic
SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)SSC-Enthusiastic (166 reputation)

Group: General Forum Members
Points: 166 Visits: 21
I think that trust has a lot to do with it but I think documented development standards go a long way to helping that along. Our DBA provided our development team with a document that lists what he expects our sql to look like. The developers have standards for the DBAs to follow when they write code. When we need to do things beyond the scope of the documents, we stop by and chat for a few minutes about the approach. Communication is key, IMO.



majorbloodnock
majorbloodnock
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1761 Visits: 3062
Nate Pink (12/10/2007)
I think that trust has a lot to do with it but I think documented development standards go a long way to helping that along. Our DBA provided our development team with a document that lists what he expects our sql to look like. The developers have standards for the DBAs to follow when they write code. When we need to do things beyond the scope of the documents, we stop by and chat for a few minutes about the approach. Communication is key, IMO.


Couldn't agree more.

Semper in excretia, sumus solum profundum variat
Rudyx - the Doctor
Rudyx - the Doctor
SSCertifiable
SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)SSCertifiable (6.1K reputation)

Group: General Forum Members
Points: 6075 Visits: 2503
... hmmm ... sounds a lot like process and procedures to me ... as for the communication, well does that not ring true to professionalism and responsibility ???

Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
tlfan
tlfan
Old Hand
Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)Old Hand (376 reputation)

Group: General Forum Members
Points: 376 Visits: 11
As a developer I am a bit upset with the tone of this editorial. The implication being that developers are incapable of anything related to the database like design or even simple data extraction. The major problem I see with this is that the scenario you describe - developers throwing some specs over the wall and getting a database or stored procedure in return - seems to avoid the major goal of the exercise: to provide the business with software that will enhance and further their process. Too often, dba's and other infrastructure folks (and admittedly a few developers), are isolated from the business needs. And if you don't know what the business needs, how can you provide an optimal solution? I would suggest that a database designed in this fashion will often miss the essential need that business is trying to solve.

I do agree with the comments on trust. It is important that folks in all areas of the development process can rely on and trust one another to do what is best. And it is also important to realize that we are all here to server and further the common goal of the business we support.



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search