June 28, 2019 at 12:00 am
Comments posted to this topic are about the item Organisations and Technical Apartheid
June 28, 2019 at 11:11 am
Good article, David. You're often the first to respond to anything Steve writes, guess I'll be the first today. 🙂
Antidotally, I've been surprised by this DBAs vs developer divide in my current job. I now work in a large IT shop, so I suppose I should be surprised. Silos seem to exist, especially in larger IT shops. In my previous job there were only a couple of us - their simply couldn't be a divide, but now I realize that was not really reflective of many organizations.
Agile, and especially DevOps, is making its way into my current organization, although it is at the moment temporarily derailed. I'm sure it will pick up in due course.
Rod
June 28, 2019 at 11:58 am
Ah, now I get it, we're going back to being the "one-stop-shop for MSSQL DBs" is called DevOps these days, fair enough. Nice article you wrote there 🙂
June 28, 2019 at 12:50 pm
Excellent post Dave, and not just because I got mentioned. Ha!
Seriously though, I think you're hitting the nail on the head with this one. Now, I work for Redgate, so please, everyone, buy lots of licenses for all our tools. That said, to make DevOps work, you have to change the culture first. DevOps really is all about communication, not tools. I give lectures on this all the time. I'm putting together a precon on it (to be delivered for the first time at SQLSaturday Indianapolis for anyone interested) and I'm going to open and close with the importance and needs for cultural and communication shifts first, tools and process second. Now, I'm also going to blatantly steal from you and incorporate Conways Law as well.
"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
June 28, 2019 at 1:14 pm
DBA - Don't Bother Asking; I like that. As a developer, in my career, I have encountered two DBAs, one SQL Server and the other DB2, that their standard answer to any question was "No". But I have worked far more DBAs that have been helpful. I was the lead developer for creating a new volunteer registration system and I had a great DBA assigned to the project. He designed the tables based on the requirements, created stored procedures to send notifications, and created triggers for auditing and also notifications. His work was solid.
June 28, 2019 at 2:49 pm
If you have an IT organization where departments (ie: developers and DBAs) are physically or culturally isolated, then conflict is only temporary. What it becomes over time is a cold war environment where folks just stop asking things of each other and lower expectations. Ultimately, it leads to technical stagnation and puts the organization on a competitive disadvantage.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 28, 2019 at 5:50 pm
Excellent extension of Conway's Law - precisely the word used here to describe the c*** frequently encountered, authored by devs at customer sites. But why? Perhaps a major contributor is the failure on the part of upper management to understand the imperative nature of in-vocation education in technological disciplines. C*** code, born and bred in SQL 2000, being churned out in 2019, and a face-palm is inevitable. Reach down the wire and give that dev a slap, comes to mind.
As a hybrid DBA-DEV, embedded alongside most of the dev and QA team, we all get along really well, and information/education-materials, are well-received. So, part of the solution, i.e, cutting down on c*** code, is for those with appropriate skills to brown-bag-session, or write single-topic bulletins, or code-coach alongside Devs, not just in T-SQL, but like Brent O's course, "Think like the Storage Engine". These help non-DBA-skill folk to get at least a 101-level covering what it takes outside Dev-land, to host and support their code and schema designs.
Both roles can benefit from cross-pollination. I'd venture that a Dev with DBA knowledge is a better Dev, and a DBA with Dev knowledge likewise is a better DBA. Wholeheartedly support the bringing down of silos - embed, and assimilate skills by osmosis at the very least!
While we're here, it really wouldn't hurt Product personnel to get in on the 101-level stuff, too. Far too often, Product-chasm-Dev, and Product-chasm-DBA, un-bridged voids lead to c****y Product designs, which inevitably cascade, like that-which-runs-downhill, into manifest c*** code and schema.
Cheers!
June 28, 2019 at 7:15 pm
I'll second those thoughts. I worked in a 4 person shop before, and I had my hands on everything from the end-user experience to the database to the .NET pages, and a bit of networking stuff too. It really helped me see how everything worked together to provide the end product to the users, and it made our team better since we couldn't afford to say something wasn't in our lane.
July 1, 2019 at 2:33 pm
Raise the technical bar--I have yet to see a dev team where doing this did not work. Developers are intelligent and talented. Trust them to come up with it. I expect developers to have a modicum of DBA skills, and to assist DBAs to do their jobs. Doing otherwise is just silly. I have seen a few DBAs who thought their job was to prevent data from being used by applications. That is just as silly. Data is only valuable when applications can consume it. Developers and DBAs need to consider the business cases for their applications and data, and focus their efforts on bringing bottom-line value. Technical apartheid is antithetical to bringing value and making money.
Edited to add another thing: I have noticed that people who gravitate to developer and DBA roles tend to have different personality types. Developers tend to be collaborative, DBAs tend to be more authoritarian, which is a good thing. The people responsible for database availability need to lay down the law about what practices are acceptable. When you strategize about communication techniques, it might pay to consider the personalities involved.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply