December 9, 2007 at 6:12 pm
Comments posted to this topic are about the item Software Teams
December 10, 2007 at 1:55 am
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, suus solum profundum variat
December 10, 2007 at 5:57 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 10, 2007 at 8:21 am
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 ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 10, 2007 at 8:41 am
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.
December 10, 2007 at 8:55 am
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, suus solum profundum variat
December 10, 2007 at 9:10 am
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.
December 10, 2007 at 9:12 am
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, suus solum profundum variat
December 10, 2007 at 9:29 am
... hmmm ... sounds a lot like process and procedures to me ... as for the communication, well does that not ring true to professionalism and responsibility ???
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
October 31, 2012 at 4:56 am
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.
October 31, 2012 at 7:48 am
One of the best comments on trust I ever heard was this one:
"When a train goes through a tunnel and it gets dark, you don't throw away the ticket and jump off. You sit still and trust the engineer."
We just have to learn to sit still longer, that's all. We are so conditioned today to immediately not trust people from the get go...:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
October 31, 2012 at 8:32 am
TravisDBA (10/31/2012)
One of the best comments on trust I ever heard was this one:"When a train goes through a tunnel and it gets dark, you don't throw away the ticket and jump off. You sit still and trust the engineer."
We just have to learn to sit still longer, that's all. We are so conditioned today to immediately not trust people from the get go...:-D
It's a great quote, but a little misleading because it lacks context. Before you get on the train, you already know a whole load of background stuff about the train operator (rail safety stats, the fact there are legal requirements, health and safety laws and so on).
I don't believe we are conditioned to not trust people, but we are conditioned to be cautious. That means taking a few relatively safe calculated risks to build up a better picture, then trusting or not based on real evidence. When we take on a new administrator (DBA, sysadmin etc.), we don't promote their account to God rights the day they walk through the door; we sit down with them and steadily hand over important systems over time, evaluating how they act as we go. We're not distrustful of them, but similarly we're not treating trust as binary (I think I used that term in one of my posts last time this editorial was published).
Semper in excretia, suus solum profundum variat
October 31, 2012 at 8:54 am
majorbloodnock (10/31/2012)
TravisDBA (10/31/2012)
One of the best comments on trust I ever heard was this one:"When a train goes through a tunnel and it gets dark, you don't throw away the ticket and jump off. You sit still and trust the engineer."
We just have to learn to sit still longer, that's all. We are so conditioned today to immediately not trust people from the get go...:-D
It's a great quote, but a little misleading because it lacks context. Before you get on the train, you already know a whole load of background stuff about the train operator (rail safety stats, the fact there are legal requirements, health and safety laws and so on).
I agree with your train operator logic. However, many times, particularly with quotes, you have to look at the overall message the quote is trying to convey to you. Quotes aren't always meant to be taken absolutely literally. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
October 31, 2012 at 9:02 am
TravisDBA (10/31/2012)
majorbloodnock (10/31/2012)
TravisDBA (10/31/2012)
One of the best comments on trust I ever heard was this one:"When a train goes through a tunnel and it gets dark, you don't throw away the ticket and jump off. You sit still and trust the engineer."
We just have to learn to sit still longer, that's all. We are so conditioned today to immediately not trust people from the get go...:-D
It's a great quote, but a little misleading because it lacks context. Before you get on the train, you already know a whole load of background stuff about the train operator (rail safety stats, the fact there are legal requirements, health and safety laws and so on).
I agree with your train operator logic. However, many times, particularly with quotes, you have to look at the overall message the quote is trying to convey to you. Quotes aren't always meant to be taken absolutely literally. 😀
Agreed, and when I looked at the overall message I saw it was flawed. Instead of just a choice between blind trust and blind panic, there's a third option - that of informed decision.
Semper in excretia, suus solum profundum variat
October 31, 2012 at 9:13 am
Good point. I have never researched a train company or an airway before I got on to one in all the years I have travelled. 😛 Guess maybe i should have, but I never really did. I wonder how many people really do this anyway?:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply