January 2, 2014 at 8:31 pm
Comments posted to this topic are about the item Breaking Down Barriers
January 3, 2014 at 1:03 am
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?
January 3, 2014 at 1:18 am
:rolleyes:
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).
January 3, 2014 at 1:54 am
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!!!
January 3, 2014 at 3:21 am
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.
January 3, 2014 at 3:23 am
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
January 3, 2014 at 3:43 am
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.
cloudydatablog.net
January 3, 2014 at 5:21 am
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.
January 3, 2014 at 6:01 am
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.
January 3, 2014 at 6:26 am
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....:-D:-P:w00t:
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
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);January 3, 2014 at 6:34 am
I personally think the problem's a bit overstated.
As a developer I think I've probably butted heads with every DBA I've ever worked with and, as long as it remained professional, that was fine. Sometimes I had to give ground, sometimes they did. Usually we both did. We all still came in to work the next day and were good freinds again by the end the week because, despite a bit of stress in the moment, we achieved the goal and that really was what we both wanted.
I have worked with a very few genuinely hostile DBAs but anyone who's that hostile is also, by definition, also unprofessional. At that point it's really a problem for the HR department rather than us as an industry. And in the interests of even-handedness I should acknowledge that I've dealt with quite a few hostile developers as well. There's <insert profanity of choice here> in every walk of life. It's not a problem with our industry, it's a problem with a few individuals.
And if you think the relationship between devs and DBAs is bad you should see experience the relationship between the IT project manager and the combined heads of every other department in the business is like. Frankly you DBAs are kittens.
If you can't educate the other person, perhaps you need to educate yourself
That or you're not shouting at them loudly enough.
January 3, 2014 at 6:57 am
The first is to put them on the same team. Too often DEV, OPS, DBA, are all split. The most successful teams I have worked with, these teams are one and are responsible for a given set of products. They are all responsible for the product and sink or swim with the product. This generally makes the products more successful and removes the division the most IT shops face.
January 3, 2014 at 7:08 am
How to solve these issues:
1. Check your ego at the door.
2. Understand that the other has a job to do and to open your mind to their viewpoints.
3. For most of us, problems are not the end of the world. No one is perfect and mistakes will happen. Being angry about it does no good. Unless you are truly saving lives or are a rocket scientist, the problems we have are generally pretty tame.
4. Be open to learning new things.
5. Treat others as you wish to be treated.
Tom
January 3, 2014 at 7:13 am
mister.magoo (1/3/2014)
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....:-D:-P:w00t:
A grain of truth to this perhaps. Both roles tend to respond to the incentives, positive and negative of the environment they are in. "Get it done fast" tends to be the motivator for programmers in many environments. Where DBA's tend to be directed more to "Make sure we can get it done, now and forever".
The most important people to educate are those in charge, and the hardest to educate as well, it seems.
Still, I very much like the idea of each role having to walk a mile in the other's shoes. Most people are reasonable, on a good day. If they understand the ramifications of their actions, they tend to be willing to cooperate with the process a bit more.
The other solution would be to hire only DBA's, and then make some of them programmers. 😉 Seriously, I've found it easier for a DBA to be a good programmer, than the other way around. However, I'm sure there are those who would, and will, disagree.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
January 3, 2014 at 7:40 am
I'm a developer who fell into the DBA role because we had no DBA. So for years I was 80% developer, 20% DBA, before I switched into full-time DBA. I think it's resulted in me being a more pragmatic DBA because I still remember what it's like to ship a release against a tight deadline. And honestly, I rather miss coding.
In the end, while I am responsible for the health of the servers and the integrity of the data, I believe my ultimate responsibility is to deliver solutions that enable the business to achieve their goals. And that sometimes means speed of project delivery over completely optimized database operations. I'd rather enable than obstruct.
In my limited experience, because I'm willing to help, developers who are weaker with T-SQL will seek me out and ask me to assist with complex queries. Those developers end up learning a lot about T-SQL and need less help in the future.
Have I let some queries go that make me cringe? Sure. But I also know that I've written some cringe-worthy queries in the past for code that had to be delivered quickly, and miraculously they didn't result in significant impact on database efficiency. So I have a lot of sympathy for developers who are under the gun.
Viewing 15 posts - 1 through 15 (of 40 total)
You must be logged in to reply to this topic. Login to reply