Your allies in IT: The Ops crew

I've always worked in shops where the 'Development' side of the house produced applications and the 'Ops' side of the house ran those applications.

If you've never heard the term 'Ops', that means the folks that manage data storage, migrate programs from environment to environment (dev to test to cert to prod, etc), and FTP files back and forth to clients. If your company deals with printed materials (statements, bills, etc.) it's the ops folks that produce these. They might also manage tape libraries, migrate applications from old servers to new ones, or manage your virtualized environment. In short, they take all the stuff developers produce and put it to use so the company can make money. They're the ones that RUN your application.

Today, I'd like to present five things every developer should know about Ops.

Ops is NOT boring and repetitive work
Ops is about efficiency and proper execution. To be good in ops, you have to understand the resources the applications use (disk, processor consumption, printers, etc.) and know how to continually improve usage of these finite resources. This means lots of analytical thinking, and lots of adrenaline on days (nights, probably) when changes are made to the all important production eco-system. Ops work is most definately NOT boring unless your shop has had very good leadership for so long everything's already smoothed out and nothing ever changes.

Ops thinks Dev is a bunch of Prima Donnas
Somewhat true - Depending on the quality of your Dev shop, you may have a few unenlightened souls running around thinking they're superior to Ops in some way. Not true, Kemo Sabe-- and thinking that way is a good way to leave valuable bridges unbuilt. Many times I've had my skin saved by Ops personnel willing to work a little harder to restore a dataset or run some special fix-it job that will cover a mistake I'd made. (Sometimes they even concoct the scheme necessary to fix things.) It's easy for the Dev-Ops relationship to be somewhat adversarial, though, if there's not mutual respect. In that case the Ops guys can be like the fabled Chinese philosopher who just waited by the river for the body of his adversary to come floating by. In this case, a friendly Ops ally can fish you out and resuscitate you-- if you've invested in building the relationship. If you haven't they just have to wait and sooner or later laugh at you when your application goes belly up and you need a special favor.

Ops is a dead-end job - NOT!
Definately false. Ops gives you the perspective needed to understand your shop's core business. You have to know the way things work and the deadlines associated with application run times. Ops also has to have a handle on online (transactional) operations and the SLAs associated with them. Ops jobs can definitely lead to strong management positions (i.e. the CIO-type career path), if that's your desired career progression.

Ops knows who you are
They quickly pick up on who's who in the Dev side of the shop-- sharp Devs can be granted extra priveledges at crunch-time while Dev Bozos will almost certainly be subjected to every stringent by-the-book mandate they have available. Ops will ultimately be given this power, because they feel a lot of the pain when things go wrong. So if a particular Dev/Architect type has caused them problems in the past, that Dev is going to have a rougher time getting things done. (Getting things done is what ultimately leads to Dev promotions and pay raises, so this is an important consideration.)

Smart Ops shops pay a little more
It is true that some Ops jobs don't require a CS degree or any particular certifications. Your company can hire people with a limited skill set-- but only if your work is largely one-dimensional and so simplistic it really doesn't require much thought. But if your work is heterogeneous and you have many time-sensitive deadlines and resources to balance, your shop will be money ahead to pay for good analytical thinkers. The very best shops I've seen have hired entry-level people to start, then paid them well enough to keep them around for many years. If they've hired smart (though inexperienced) people, those people will accumulate valuable knowledge as time goes by and will yield an incredible ROI over time as they keep your IT machine smoothly running. A single salvaged SLA can pay for a lot of marginally bigger paychecks!

So if your shop runs production applications, I'd urge every Developer and Architect to adapt the right mindset towards our friends on the Ops side. It'll pay off, big time!

'Till next time,

Happy Coding!