I turned in my two-week notice today. I was working for a fairly large company doing WebSphere Administration and Java development. My new job is IT Director for a much smaller organization. It'll give me the chance to put into practice my own take on IT on a (relatively) clean canvas.
It's bittersweet leaving my current job. I enjoy the camaraderie of my fellow developers, but the IT department itself leaves much to be desired. There are some very smart folks, but they don't get the opportunity to demonstrate it on a consistent basis. Over the past couple of months, we've been hemorrhaging people. Today alone, 3 people turned in their resignation. In the past 6 months, they've lost 6 other high quality employees. Without going into too much detail (in order to protect the guilty), I'm going to use this post to explain why.
IT in Corporate America (herein after referred to as CA) doesn't have to suck. But by and large, it does. Why don't the smart people who work in CA get the opportunity to show how good they can be? Part of it comes by being saddled with inferior tools: bad version control, bad testing tools, bad test data, bad languages, bad platforms. However, these are technological problems that have good technological solutions. Why aren't they embraced? Why use Serena or Harvest for version control when there's svn and git? Why does it take 4 hours to find a user id in development to test a change that took you 30 minutes to implement when a daily refresh of test data would solve the problem? Why buy expensive monitoring software that accomplishes nothing more than sending out snmp messages to a blackberry when you can use nagios for the same thing? And finally, why do the people who propose these changes never, ever, ever get listened to?
The facile answer is to blame management. And, there's something to that. IT Management needs to bear the responsibility for allowing the organization to dismiss their smart people as "friggin nerds" or pie-in-the-sky dreamers. But the problem runs deeper and these phenomena are merely symptoms. The underlying problem is CA's addiction to business-centric IT.
In CA, IT costs are looked upon as necessary evils. CA needs computers and email and Web sites, because that's what CA needs to function and be profitable. Other than that, the IT department can kindly piss off, thank you very much. But oh, before you do, can you add that new feature I discussed to our Web site by next Thursday? Then go piss off, until trades get botched on Friday night, whereupon I'll need you to spend the next 48 hours figuring out what the hell went wrong and why we lost $150,000 dollars.
Most CA IT shops try to solve this problem with processes. They develop SDLC's and design documentation and have change control meetings. These processes do a decent job of mitigating damage caused by rogue change. What they don't address is how change gets introduced and, more importantly, who drives the change.
The majority of changes in CA IT are driven by the business. This has the effect of turning corporate IT into an order taker for the business. The corollary of this is that IT doesn't have the ability to create and drive their own changes. IT infrastructure changes don't immediately (or obviously) fit into any specific business goal – at least from a business perspective. Why should the business care about getting new servers or having developers waste their time rewriting already functioning code? It's anathema to them – at least until IBM stops supporting that version of WebSphere. Unfortunately for the business, this strategy works in the short term. You don't start to see problems until you're well down the path of no return. The code base increases in complexity and redundancy because the entire thing is one layer of band aids on top of another. Now that “simple change” becomes a nightmare of an ordeal because it's impossible to identify all the interaction points. And, without a repository of automated testing scripts, the developer is forced to wonder what all he might have broken. We've had instances where a change introduced on Friday is accused of breaking production on Monday only to find out that it has, in fact, been broken for the past 6 months.
Corporate IT needs the ability to run their own internal infrastructure projects without needing permission from the business. The business has managed to survive this long without that change in the vesting page to convert dollar values into euros. Seriously, what's the difference if the change goes in June versus September? Why not take that 4 month period and refactor the common code base? Or convert those Windows machines running Apache over to Linux? Or research Drupal as an alternative to your current, multi-million dollar CMS that's constantly breaking? Or use nagios to get real metrics on Production uptime?
Most people in corporate IT want to do a good job. Most people in corporate IT are capable of doing a good job. Every developer I know is driven crazy by crappy code; they want nothing more than to get in there and make it better, stronger, faster. Most of the time, however, they are actively stymied from doing a good job because they can't act on their own, best instincts. Sorry pal, but that's not in the business plan.