January 10, 2015 at 11:06 am
Comments posted to this topic are about the item Selling Automation to Ops
January 10, 2015 at 1:41 pm
From the article
Ultimately we all want the same thing. Better software delivered to customers faster. We want to Ship Safe, and Ship Often.
Ah, if only THAT were true and then everything would be much better. I've found that the only thing on some "developers" minds is to "get it off my plate" and the only thing on some "ops" peoples minds is "get if off my plate".
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2015 at 3:10 am
At one company where I worked the development team worked for the support manager. This worked very well as our top priorities were to put in code to make the support calls stop. Features were driven by user requests and since all our users were in he same profession we were sure that if several users needed a feature others around the country would need the same features. This made the job of sales folks easier too. Developers worked the support desk at least some of the time.
I suggest that more developers work the support desks at least some of the time. I can almost hear Jeremy Clarkson[/url] saying: "Dealing with support call? How bad can it be?"
ATBCharles Kincaid
January 12, 2015 at 6:50 am
That sounds like a marriage in trouble where all the blame is going to one side, as if only they need to change. But in most relationships each side is responsible for themselves. Sure IT needs to change in the scenario given, but so does Operations for a truly successful marriage.
January 12, 2015 at 7:17 am
Occasionally automation means modifying the applications or developing a new table or stored procedure. But in my universe, Operations are part of IT and are capable of implementing their own automation solutions, if we're talking about things like scripting or scheduling.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2015 at 7:20 am
I couldn't agree more with the statement "I'd recommend that we learn how to automate the configuration of our development systems, as well as script our changes." This is a change I'm trying to get implemented. People are so reliant on the click...click...click to get things done, but it isn't repeatable. If we script all changes, they can be tested repeatedly and also deployed in a safe and consistent manner. Of course, the scripts have to be right, but that's another discussion. We have to get away from the click and to the script first.
We are always responsible for ourselves in anything. If developers can deliver a safe, repeatable and consistent release approach for everything, I'd say we've met our responsibilities. The "other side" can learn how to do things. They wouldn't be in their position if they couldn't. They run the release scripts and find something else to work on.
January 12, 2015 at 7:49 am
It would be helpful if backup tools supported backing up and restoring server configurations (linked servers, maxdop, trace flags, etc.) Practically all SQL Server backup solutions are database centric. Maybe I'm wrong, but as far as I know, there is no simply way in SSMS to script out server settings.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2015 at 8:32 am
Jeff Moden (1/10/2015)
From the article
Ultimately we all want the same thing. Better software delivered to customers faster. We want to Ship Safe, and Ship Often.Ah, if only THAT were true and then everything would be much better. I've found that the only thing on some "developers" minds is to "get it off my plate" and the only thing on some "ops" peoples minds is "get if off my plate".
I see that, too, and it's OK if your "get it off my plate" is helping others get things done. If it's just helping you, then I don't want you working for/with me.
January 12, 2015 at 8:34 am
Charles Kincaid (1/12/2015)
At one company where I worked the development team worked for the support manager. This worked very well as our top priorities were to put in code to make the support calls stop. Features were driven by user requests and since all our users were in he same profession we were sure that if several users needed a feature others around the country would need the same features. This made the job of sales folks easier too. Developers worked the support desk at least some of the time.I suggest that more developers work the support desks at least some of the time. I can almost hear Jeremy Clarkson[/url] saying: "Dealing with support call? How bad can it be?"
That can work, but you also have to ensure things drive forward, as well as old problems are fixed. I think MS is far to on the "Drive forward" side with SQL Server and not enough on the "fix old stuff" side.
January 12, 2015 at 8:37 am
Eric M Russell (1/12/2015)
Occasionally automation means modifying the applications or developing a new table or stored procedure. But in my universe, Operations are part of IT and are capable of implementing their own automation solutions, if we're talking about things like scripting or scheduling.
True for many of my employers, but often the Ops people don't know how to implement automation, or how to work with the development team to manage their systems. Once you start to think about a larger scope of smoother work, you realize that Ops needs to move at the speed of development to creation/config/management of environments. And if you realize that breakage from development comes from not scripting (And clicking GUIs), then developers realize they need to deploy their config as well as their bits to Ops, then things get better.
By working together, we share some knowledge, and then responsibility, which hopefully gets things running smoother overall.
January 12, 2015 at 9:41 am
It isn't safe to assume that only "Operations staff see (some other group) as wild and irresponsible". I have personally witnessed operations people applying updates without following the process, resulting in every system in an organization being brought down. Both sides need to follow established processes, and both sides need to stop pointing fingers. As they say, there is no "I" in team.
Dave
January 12, 2015 at 9:44 am
Charles Kincaid (1/12/2015)
At one company where I worked the development team worked for the support manager. This worked very well as our top priorities were to put in code to make the support calls stop. Features were driven by user requests and since all our users were in he same profession we were sure that if several users needed a feature others around the country would need the same features. This made the job of sales folks easier too. Developers worked the support desk at least some of the time.
I like that process, although it seems to be somewhat unique. In my experience, Marketing normally drives the development process. Their commissions are based on sales, and sales come from new features. Bug fixes don't sell product.
Dave
January 12, 2015 at 10:53 am
Over the last 15 or so years of the thirty or so I have worked, I have been on both sides of the fence interchangeably. Years back in the industry, we had what was called a Systems Programmer. The tasks these people did was really interesting since they were working close to the system and the business at the same time. I have worked somewhat in that role over the past years.
When operations need something and it is a programming need, I have stepped in from time to time and done what is needed. This is stuff like writing custom report providers for SSRS, generic .net custom controls to provide two-phase security to meet EPA/DOJ security requirements, and query of IIS applications to determine and cross-ref the app inventory on multiple servers.
Providing this type of service is the best way to understand the needs of both teams, as well as to understand the chasm that can and often does exist. As one working both sides, it also gives you opportunities to speak with both developers and operations as peers. It can be very beneficial.
M.
Not all gray hairs are Dinosaurs!
February 9, 2015 at 6:28 am
I have found that within software departments where they develop products, as opposed to in house applications, that there is more likely to be a developer rotation into support. There also tends to be a common attitude to it by all who have completed at least one rotation: they don't want to do it but see the benefit for the product, the company and themselves. A bit like eating your greens, I guess.
A number of development teams that I have worked on over the years truly wanted to be a part of the whole process and developed deployment scripts that they were prepared to do to the requirements of the operations teams.
Occasionally, you do get lazy teams and the following are examples of poor attitudes that I have come across:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 10, 2015 at 9:33 am
Gary I think the process that you are referring to is called "dog fooding". It refers to eating your own dog food. I had some deep experience with that at the company that wrote software for dentists. We managed to find a way to use almost the entire suite to support the support efforts.
ATBCharles Kincaid
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply