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 12345»»»

Breaking Down Barriers Expand / Collapse
Author
Message
Posted Thursday, January 2, 2014 8:31 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 7:12 AM
Points: 31,284, Visits: 15,746
Comments posted to this topic are about the item Breaking Down Barriers






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1527338
Posted Friday, January 3, 2014 1:03 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 3, 2014 6:04 AM
Points: 1, Visits: 7
DBAs and Developers are at times both purists but I find that developers tend to be a little more pragmatic in allowing some things to wait until a refactoring exercise.

For DBAs though it is a little different as they work a little more isolated from the end users and know that a mistake or shortcut early on can (and often will) lead to a serious time cost later on in reworking a schema.

Education is key so that both parties understand where each comes from. Decisions need to be made together and where necessary arbitrated by an architect or third person who is neither a dev or a DBA.

I am a dev though so maybe my impression is a little skewed?

More communication and less criticism is the key as we are all working to the same goal - aren't we?
Post #1527371
Posted Friday, January 3, 2014 1:18 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Yesterday @ 7:14 AM
Points: 56, Visits: 394


One of the issue I come across is that some developers believe that writing a stored procedure or even a set based query will slow them down from cutting code and prevent them from bug fixing.

They dont always want to see that requirements of the project include:getting the project completed, having maintainable code, and performance has to be at least acceptable.

But the main difference is the mindset: trigger-happy vs belt and braces (plus some scaffold...). The right answer is, of course, it depends.

Even some dbas have this trigger happy mindset which to my experience has caused all sorts of issues. And some developers have even more of a stick-in-the-mud mentality and wont consider that there are other ways of working (bit like some of the dba I have known).



Post #1527378
Posted Friday, January 3, 2014 1:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:46 AM
Points: 5,750, Visits: 3,672
I think that sometimes the friction exists because of a fundamental lack of understanding about the longevity of different software artifacts and the effort it takes to change them.

If we consider database schemas and .NET web services, for example, it is easy to alter an algorithm applied in a web service as it just requires a redeployment of, perhaps, just a single file whereas as change in a column definition may require changes to multiple views and stored procedures, constraints, security, other applications as well as a possible "data fix".

3GL programmers should be very strict when it comes to their interfaces but are generally more free to be relaxed when it comes down to the implementation. Similarly, perhaps DBAs can be more relaxed with the stored procedure implementations compared to their interface (e.g. any exposed views), the logical model and the physical implementation. After all a stored procedure's internal implementation can be altered without necessarily affecting any calling code.

That said, we should all be trying to do they best job we can under any given circumstances all the time. Laziness (in knowledge or implementation) due to "agility" is no excuse.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1527385
Posted Friday, January 3, 2014 3:21 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, January 3, 2014 8:04 AM
Points: 25, Visits: 41
One good way is to periodically put DBAs to work within a developers team and the reverse. For my experience, developers should not take SGDBs abstractions as granted and having a DBA on the team helps evaluating and anticipating real world behaviour of the code; likewise, DBAs would have a glimpse of the pressure and time constraints that are so common on developer teams and maybe this could lead to development of better (deployment, maintenance, ..) processes. Having developers working within a DBA team would teach the long term consequences of bad designed code and the pressure that these teams usually are so that things just work, no matter what.
Post #1527422
Posted Friday, January 3, 2014 3:23 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 3:19 AM
Points: 659, Visits: 243
Education, communication, understanding: they are all critical in resolving this issue.

My DBA background was initially as a developer in FoxPro where the code and the database are deeply connected. This followed a migration of the database to SQL Server and a period where I was both the DBA and lead developer. In such a situation, you acquire a deep understanding of the relationship between code and database, and can easily guide the developers in the right direction. But where DBA and developer teams are separated both physically and intellectually, I can understand just how much of a challenge it is to get this meeting of minds.

Difficulties and a lack of understanding will often arise where the test data provided to the developers is not really illustrative of the production data. If the development database is too small a subset of the production data, or even worse, is only a dataset generated by the developers themselves, then it can never be a suitable platform for real-world testing. So often, the code is first deployed against production data only during the final acceptance testing, by which time code which seems quite suitable when tested against the development data set is deeply baked in. Even in the early stages of code development, it is important to test against data that is sufficiently complex and representative of the business domain to enable the development team to design realistic tests.



Tony
Post #1527425
Posted Friday, January 3, 2014 3:43 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 11:03 AM
Points: 108, Visits: 814
Another vote for having the developers and DBAs to be working side by side in the same team.

So divisional teams based around products with a single manager for both. Functional teams produce experts very good at implementing policy (eg security) but can lack in practical implementation of usable products.

A lot of the time I think it comes down to aligning the motivation of the individuals to the task at hand.

There will be times when you have to go quick and dirty. Having developer and dbas working closely together in my opinion lends itself to compromise and flexibility much better which I think usually ends up with a better end result.

Sitting in the same office you sometimes overhear things and if its serious you can jump in and say - guys that is going to cause some other problems how about this alternative.
Post #1527434
Posted Friday, January 3, 2014 5:21 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 5:35 AM
Points: 2,914, Visits: 1,847
Tony Bater (1/3/2014)
Education, communication, understanding: they are all critical in resolving this issue.


Only needs that to be bi-directional and you've got the solution.

There is an inherent conflict here. A DBAs job is to protect the data and provide the shared data to all consumers reliably.

While an organisation is small a developer and a DBA have the same goals albeit in different but related disciplines.
As an organisation gets larger the developer community gets larger and tends to fragment. They may have responsibility for a particular part of the technical estate and therefore lose the "for the good of all" mentality. My observation is that this gets worse as the organisation grows.

DBAs tend to be a much smaller community and the nature of what they do requires them to keep their area of responsibility functioning for the benefit of data consumers.

Organisational size causes fragmentation across all business disciplines. Marketing, engineering, sales, finance, legal & compliance, IT. Once you've seen a punch up between a sales guy and a marketing guy the depths of human stupidity will become clear.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1527464
Posted Friday, January 3, 2014 6:01 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, October 2, 2014 10:03 AM
Points: 3, Visits: 43
If the stereotype is strong on both sides within an IT department, the first step is going to be the hardest and that is a mutual respect for one another, laying aside those biases toward the goal of acceptance and understanding.

From there it is a issue of knowledge and information. All developers--those who truly want to take their careers to the next level, imo--should educate themselves in database architecture, relational models, optimizing SQL techniques and security and some database administration. The DBA(s) should do likewise in software engineering, OR/M, unit testing, etc.

Neither side should feel they need to master the other, unless that's a personal goal. If so, that's commendable!

For the software developer, another goal would be to include the DBA as part of the development cycles, working with them on data modelling, query optimization, security and deployment considerations.

I am a software engineer with 20+ years experience but that experience also includes a vast background on Oracle (administration and PL/SQL), then later on SQL Server (admin and T-SQL). I gained invaluable knowledge and experience and I believe that I am a better developer because of that investment.

I've passed this philosophy onto my development team as well, instilling in them the importance of database architecture, database administration and to write better code using that knowledge. I continue this tradition and it continues to pay off.
Post #1527474
Posted Friday, January 3, 2014 6:26 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 12:13 PM
Points: 1,805, Visits: 5,868
Hey, come on it's not the DBAs or the Programmers that are the problem, it's the Project Managers that we should be worried about, those good for nothing....

I am glad to say that I have never worked in a business where the DBAs and Programmers have anything but positive attitudes towards each other.

If there is ever friction, I would imagine it is caused by lack of respect for the other person's knowledge and understanding and in those circumstances all you can do is educate (ignoring the more volatile solutions).

If you can't educate the other person, perhaps you need to educate yourself - that's why I visit SSC and other forums - to educate myself in the dark arts.


MM


  • MMGrid Addin
  • MMNose Addin


  • Forum Etiquette: How to post Reporting Services problems
  • Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
  • How to Post Performance Problems - by Gail Shaw

  • Post #1527482
    « Prev Topic | Next Topic »

    Add to briefcase 12345»»»

    Permissions Expand / Collapse