Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Software Teams Expand / Collapse
Author
Message
Posted Sunday, December 9, 2007 6:12 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 3:31 PM
Points: 33,051, Visits: 15,159
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
Post #431111
Posted Monday, December 10, 2007 1:55 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 4:57 AM
Points: 1,049, Visits: 3,002
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
Post #431213
Posted Monday, December 10, 2007 5:57 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 12:29 PM
Points: 15,501, Visits: 27,886
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 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #431273
Posted Monday, December 10, 2007 8:21 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 7:54 AM
Points: 3,187, Visits: 2,280
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."
Post #431351
Posted Monday, December 10, 2007 8:41 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 3:31 PM
Points: 33,051, Visits: 15,159
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
Post #431364
Posted Monday, December 10, 2007 8:55 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 4:57 AM
Points: 1,049, Visits: 3,002
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
Post #431376
Posted Monday, December 10, 2007 9:10 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, November 22, 2013 11:52 AM
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.


Post #431381
Posted Monday, December 10, 2007 9:12 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 4:57 AM
Points: 1,049, Visits: 3,002
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
Post #431382
Posted Monday, December 10, 2007 9:29 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 7:54 AM
Points: 3,187, Visits: 2,280
... 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."
Post #431392
Posted Wednesday, October 31, 2012 4:56 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, November 1, 2012 10:18 AM
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.



Post #1379241
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse