Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

5 dysfunctional IT relationships -- and how to repair them

Dan Tynan | Oct. 2, 2012
Sys admins are from Mars, developers are from Venus, and legal is from hell -- here's how to heal friction among IT factions

"In a funny way the cloud is moving this to the forefront," he says. "It's a backdoor into a chargeback mechanism. Organizations that are adopting private clouds are also finding they can use that to make DBAs and other groups accountable for their own IT spend."

Dysfunctional IT relationship No. 2: Senior developers vs. junior developers 

I'm a new software developer for a large company that desperately wants to be on the cutting edge. I'm trying to help them do that, but I keep getting stymied by the graybeards. The senior developers are always reviewing my code, and it takes forever to get approval for even a simple change. They're slowing down the company and, frankly, hurting my career. How do I tell these old dudes to back off without getting fired? Young & Restless

Old people -- when will they ever learn?

The first thing you need to realize is that maybe, just maybe, your more experienced developers might be right in being a little more cautious about unleashing insufficiently vetted code unto the world, says Joe Masters Emison, VP of research and development for BuildFax, which stores construction records for hundreds of millions of properties across the United States.

"Software is wonderful in that you can do amazing things with it," he says. "So a junior developer looks at Facebook and says, 'Gosh it would be easy to create X because all we'd have to do is change this one thing.' And if Facebook only served five people, that might work. But you may not understand what's required when you've got a large user base and a large body of code with a lot of people working on it." 

It's the senior developer's job to contemplate all the terrible things that could happen from one tiny change, he adds. The cost of even one hour of downtime thanks to a small tweak in the code could be enormous.

For their part, senior developers must acknowledge there are scenarios where rules can be safely broken -- like editing code that's already in production -- without causing the sky to fall or the company's share price to plummet.

"There are certain situations where you want to do a live edit of a database -- say, to push out maintenance upgrades," says Emison. "Or sales might come to you and say they have a customer they need to close this quarter, but it requires certain changes to the code. When the risk of anything bad happening is low, you could be better off from a business standpoint to break the quality rules once in a while."

But if you must engage in "cowboy coding," Emison advises you follow the pink sombrero strategy laid out by Joshua Siler, a former VP with marketing firm Babcock & Jenkins who is now CTO at HiringThing, a cloud-based service that helps hiring managers post jobs online and manage applicants. Siler wrote:


Previous Page  1  2  3  4  5  6  Next Page 

Sign up for Computerworld eNewsletters.