I'm a "light bulb" kinda guy

The overwhelming response I received to my previous post has led me to believe that I struck a chord with a good chunk of techies working in CA. This makes me happy. It also makes me sad because that means a large percentage of you are as fed up and dissatisfied as I am, and that sucks. Anyway, onto the post.

I'll probably be accused of constructing a straw man here, but of the folks who disagreed with me, their reasoning went something like this:

Everyone knows techies are notoriously lacking in social skills and therefore do a poor job communicating their ideas to the business. If the techies could just learn how to speak businessese, they would get listened to. If the idea saves the company money, the business will adopt it.

Well, I call bullshit. I've never understood where this notion came from that techies, as a group, lack social skills. Sure, there are a few weirdos like Hans Reiser out there, but he's no more lacking in social skills than O.J. Simpson. We may be a slightly more idiosyncratic bunch, but that doesn't mean we lack social skills. If you don't believe me, spend some time reading the comments section of Hacker News. Trust me, it'll boost your faith in humanity. It's the most erudite, courteous place on the internet. By and large, we're probably a more introspective and thoughtful group, and somehow that gets mistaken for bad social skills. Seems more of an indictment of society than of hackers. Besides, it's always the business guys who are screaming into their cell phones while sitting on the crapper. I don't know how you can get any more poorly socialized than that.

Techies don't speak businessese for the same reason we don't write apps in COBOL anymore: it's a horrible language. Businessese is full of clichés and Orwellian doublespeak. “Problems” became “Issues” which became “Challenges”. I remember sitting in one unspeakably spirit crushing [and mandatory] meeting while some guy from Franklin Covey rambled on for two hours about “Wildly Important Goals” or “WIG's”. I felt like an anthropologist on Mars. How could any normal human being with an IQ above 100 buy into this crap? At the end, some older tech guy stood up and said that he's seen this kind of thing come and go and asked, “Will we still be talking about WIG's a year from now”? “Of course you will,” Willie Loman answered. “Upper management is very committed to this program.” Guess what? In less than 6 months time no one was talking about WIG's any more. I knew it. Every tech guy/gal I talked to knew it. But God forbid you actually say it.

Programmers learn as much about the business as they have to in order to do their job effectively. Can you say the same thing about the business folks? Do they learn as much about computers as they have to in order to do their jobs effectively? Of course not. You'll never find a group who wears their ignorance of technology more proudly than the average business person. “I'm not a computer guy,” they'll say with a big smile on their face. Well gee, the personal computer is only the most significant invention to come along in the past 100 years. You'd think one might be mildly curious about how it works. If you went around saying “I'm not a light bulb guy” people would look at you like you're nuts. You may not be a “light bulb guy”, but you know how to identify one that's broken, right? Presumably, you've mastered the skills necessary to change a light bulb. Granted, computers aren't light bulbs, but I think you get the idea.

The final point, that the business will adopt a change if it's proven to save the company money, is based on a false assumption; namely, that businesses behave in a rational manner. Other than Ayn Rand, I don't know anyone who believes this. I worked at one place that decided to use Siteminder over Sun's SSO solution because Computer Associates gave them a discount on COBOL runtime licenses for the mainframe. Never mind that Sun's solution would have been cheaper in the long run, those mainframe licenses will look great on this quarter's budget! For more evidence, read Some Creep's tale:

I recently watched the tendering process for a fairly simple development project. Maybe 5 pages all said an done, all implemented inside an existing sharepoint solution.

Provider 1 quoted about what it should cost. $6000 - cost of the work involved, and a mark up for the hassle of having to spec and bid for the job, and deal with a bureaucracy on completion.

Provider 2 and 3, having had relationships with the company before, quoted 335,000 and 425,000 respectively.

Provider 1 was excluded. Obviously their quote was so low because they were a mickey mouse company that didn't understand what was required. Provider 2 was questioned closely because they were so much lower then provider 3, and eventually after much reassurance from the sales people of Provider 2, they were selected.

One of the techies from another department saw the quote and asked to see the rest of the spec, assuming there was more to the job then what he was seeing. After the project manager confirmed that no no, that was the spec on which the company had quoted 335,000 - the techie expressed his concerns that the quote was vastly too high. The project manager called back and said 'One of my advisors thinks this price is really too high' - the sales monkey put him on hold, came back about 90 seconds later and knocked the price down to 235,000.

Project Manager thinks he got a bargain. Techie got a round of congratulations. And the company spent 40 times as much on the project as they should have.

That sound rational to you?

I quit my job today, oh boy

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.