June 5, 2015 at 11:16 pm
You don't have to win to plant a seed. Even a cement parking lot, like your Dev Guy, has a crack in it. 😉
Great article, though. I hope enough people like your Dev Guy take the time to read it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2015 at 11:32 am
Certainly that dev guy had it hoplessly wrong, but you too have it wrong - not hopelessly wrong, but somewhat wrong.
During much of my career I've had customer support people, ops people, and development people working for me and an important part of my job has been to ensure that those disparate groups with differently centered skill sets do indeed act as a unified team rather than pulling in different directions.
Teams are like sets - they can be joined together to make larger teams, which in turn can be joined together to make still larger teams, and so on until maybe at some point you get to a unit that's too big to behave as a team. If communications between the diferent small teams are adequate, they will effectively become a single team (and will be many times as effective as if they dont). That certainly doesn't mean that sysops or any part of it (such as production operations dbas) are going to be subordinated to development, or that development is subordinated to customer support, or any nonsense like the Dev you describe was promoting, but it certainly does mean that all these different skills (and other functions, like license management, supplier relations, technology research, data protection conformance, avoiding conflict of interests, and so on) must work together as a team (or communicate so effectively that you can't detect that they aren't all working together as a team, which I don't really believe is any different from actually being a team) if they are to be really effective.
Tom
June 6, 2015 at 11:36 am
Jeff Moden (6/5/2015)
You don't have to win to plant a seed. Even a cement parking lot, like your Dev Guy, has a crack in it. 😉Great article, though. I hope enough people like your Dev Guy take the time to read it.
I hope they'll go further than that, and respond to it after they've read it.
One sort of response and we'll be happy that Phil has cured some of their failings :-D. Another sort and we get the opportunity to try to educate them. 🙂
Tom
June 6, 2015 at 12:01 pm
you too have it wrong - not hopelessly wrong, but somewhat wrong.
Oh dear, perhaps I've got it wrong. Let me explain a bit. DBAs, along with a lot of IT people, have a responsibility across projects. A security guy will not be tied to one particular project, but have a view across systems and projects to plan intrusion detection, and defense in depth. A network guy (or Gal) is likely to have responsibility for the network right across projects. You cannot combine teams like this with project teams. No sir. Priorities and perspective are just too different. I've worked in a lot of IT departments, managed a few, and acted in a consultancy role in many more. The ones that worked well had very clear division of roles and responsibilities but communicated well and kept excellent documentation. Everybody knew in some detail what was going on but kept focused on their own role, unless they were asked for help or had a part to play to support another team. If you combine teams just in order to get them to work cooperatively, then horrible things happen. The worst in my experience is what is usually termed 'hunting in packs' where whole groups of 'multi-skilled' people go chasing the most exciting and visible crisis or hotspot, making a lot of noise, holding a lot of meetings, but diminishing their real work to the minimum, and distracting or demotivating others. IT departments where the alpha males rule the roost always go down-hill rapidly.
Best wishes,
Phil Factor
June 6, 2015 at 12:50 pm
I can tell you from my most recent experience, that for some reason they think the network guy can do what the DBA does. It was a loosing battle for me. I think what is really scary is that these companies are putting themselves at a security risk. Going years without a DBA, and accepting slow applications as the norm. It's not wonder why we have so many identify thefts today.
My last experience was that the db developer was doing some (not much) of the dba work.
I think the thinking is that SQL Server is a set it and forget it system.
June 6, 2015 at 5:04 pm
Developers are knowledgeable about narrow topics. They think in tiny bits and move from bit to bit in the process of creating software. A truly experienced DBA thinks years down the line from the tiny bit of software the programmer creates to how does the business cope with the fact that the developer only thought about today.
For example, ALL consulting companies and most software companies think about getting the product out the door as quickly as possible ignoring the fact that when the application or database design comes under pressure it folds up like a cheap suit.
An experienced DBA will look at the design and tell you what it will be like in 5 years and give the business the correct advise on how not to waste money. Developers don't do that.
June 6, 2015 at 7:49 pm
TomThomson (6/6/2015)
Jeff Moden (6/5/2015)
You don't have to win to plant a seed. Even a cement parking lot, like your Dev Guy, has a crack in it. 😉Great article, though. I hope enough people like your Dev Guy take the time to read it.
I hope they'll go further than that, and respond to it after they've read it.
One sort of response and we'll be happy that Phil has cured some of their failings :-D. Another sort and we get the opportunity to try to educate them. 🙂
Heh... the one thing I hated about the article was that Phil let a "live one" get away without planting even so much as a seed.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2015 at 1:27 am
communication really is key. sometimes it's hard to believe that companies manage to create quite complex systems that work pretty well with rather shonky processes relying on inadequate tools when surely it wouldn't be that hard to create integrated tooling for project, requirements, build, test and release management. does such a thing exist? i have not come across it.
June 7, 2015 at 7:05 am
@Jurgen.lottermoser
Yeah. ALM was supposed to fix exactly this issue but the tool providers couldn't resist the temptation to lock their customers in to the one solution. Also, they concentrated on development and rather forgot all these other requirements. All the ALM tools seem to be very dev-focussed. I'd like to see open systems that allow you to carry on using Git, SSMS or Jira but allow you to communicate and pass data between the tools. Communication systems that are used between people are usually poor. there are few system that provide reliable tracking or alerts if the response takes longer than a set period. you can never get reports that track the performance of people in closing issues. Worse served even than DBA are the support people who have to maintain an application in production. It is usually really difficult to get fixes for all the common user problems from the devs, and proper escalation procedures so that irritated users aren't left fuming for hours or days with an application they can't use. Yup. Been there.
Best wishes,
Phil Factor
June 7, 2015 at 10:06 am
The best communication methods and systems in the world are totally useless unless a company adopts a development and maintenance policy that few companies seem to implement and can be summarized in just one word... Discipline.
There have to be correct and adequate company standards and then everyone in the company must follow them in a disciplined manner or they simply won't work.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2015 at 3:07 pm
Phil Factor (6/7/2015)
Also, they concentrated on development and rather forgot all these other requirements. All the ALM tools seem to be very dev-focussed. I'd like to see open systems ...
I should probably point out that I am a dev.
is this the kind of thing you had in mind: Open Services for Lifecycle Collaboration
came across this while reading up on AML
June 8, 2015 at 12:00 am
Comments posted to this topic are about the item The Multi-skilled Developer
Best wishes,
Phil Factor
June 8, 2015 at 2:53 am
I am looking forward to the time when the devs take over application support - can't be that hard as the application is always developed without bugs, ain't it?
June 8, 2015 at 2:56 am
I should probably point out that I am a dev.
I'm basically a Dev too.
I am looking forward to the time when the devs take over application support
I'm told that some agile teams at Amazon are doing precisely this. I'm finding it hard to discover how successful they've been! Anyone else know?
Best wishes,
Phil Factor
June 8, 2015 at 5:30 am
@GrassHopper "Developers are knowledgeable about narrow topics. They think in tiny bits and move from bit to bit in the process of creating software." That's a bit condescending don't you think? There is no need to denigrate an entire group of people to show how much better DBAs are. If we are to take a lesson from Phil's discussion, it is that there are multiple areas of expertise that should be working together, and no one group is better than all the rest, because it takes all the groups: development, DBAs, server admins, security & network experts, etc, to make a viable product.
As a developer who has done a stint as a DBA for a couple years, I've learned that you can't be everywhere at once, and that a truly good developer has a wide scope and can see the big picture while also recognizing their own limitations. I am definitely better suited to being a developer myself, and while I may be great at designing relational tables, writing complex queries and analysis cubes, I work ~with~ our DBAs by getting their input on my design ideas, and relying on their expertise in storage and performance tuning. If all developers only thought in tiny bits, all software would be cr*p. Good software comes from developers that do have a wider skill-set, do think long-term, and do recognize the functional boundaries of their abilities and work with other teams to bring an idea to fruition.
-VG
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply