Next post won't be SOX, I promise.
Reading Wikipedia's entry, it linked here, for how IT can be brought in line: http://en.wikipedia.org/wiki/COBIT
A few of the things stood out as being a sort of antithesis of the startup, beyond just outright sucking...
Implementing processes and having people man those processes, complete with technical access controls. This mean you can't walk over to someone's desk any more, or even call them on the phone, and ask for something. It has to go through, for example, a request tracker. If you walk over to someone desk's, they'll be forced, by law, to send you back to your own desk and send them a ticket for your request. The net result is face to face interaction is greatly reduced, and team participation gets turned into servicing anonymous requests by faceless people in a personalityless queue.
Seperating development operations out into:
* Plan and Organize
* Acquire and Implement
* Deliver and Support
* Monitor and Evaluate
This means that, by law, if you're the programmer, you're not allowed to think of nicities to make the product better. Nor are you allowed to tweak the running system, or even have access to it, but instead are instead required to throw your work over the proverbial fence for someone else to put it online. I watched this company I'm with suffer for weeks trying to track down a serious bug that occured in production but couldn't be reproduced in development, trying to pass trouble shooting tips over the wall and wait for pieces of information that might be somehow useful to come back over. It was as graceful as trying to open a Chinese puzzle box with a RadioShack Robby the Robot. And now we're hearing talk of assembling an architectual team, meaning that some people architect and others program. The people most qualified -- nay, the only people qualified to suggest refactorings are those who have their noses in the code day in and out, who are actually trying to do things with it. I'm sure there will be lots of illicit whispering between the two camps, but the net result is still the people doing the designing are robbed of knowledge with witch to design and the people doing the implementing are robbed of insight with which to execute their implementations, and everyone is collectively robbed of the freedom to quickly, easily, efficiently, and effectively form ad-hoc swat teams composed of the individuals who have the right combination of knowledge of the parts of the system, engineering, and available time.
This place did, honest to God, have a startup feel to it. Now they're rapidly expanding -- a minefield unto itself as it increases the number of hops requests must go through and the amount of each person's time dedicated to serving as a routing intermediary node -- and on top of that, there's all of this additional process and forced specialization. So, it'll be interesting to see what it looks like for the startup nature to fall apart, and how long it takes.
On the subject of scaling, it occured to me the diminishing returns of each hire, and my role, being the 800th, or 500th, or whatever person here. How much damage can I do? How much damage can I do giving the extremely complex structure with which I've been placed into? Given the business constraints and the very narrow focus of my group at any moment, what are the odds that I'll contribute anything that comes anywhere near what the members of the team that wrote the code did. Each newly hired programmer represents radically diminished returns. Urges in myself to do radical things -- from climb up into the half way exposed ductwork to go research, to refuse to implement functionality and just do janitorial work in the code -- stem from this until-recently-subconcious parephrial awareness. Somethings not right about me being here or what I'm asked to do -- not something horribly or fundamentally wrong, just a certain futility. If I can't do any actual rocking, why not regress and cater to primal urges, like climbing? If I can't do anything that'll add big whoopass cans of business value, why not just make life easier for the poor saps that don't realize they can't and clean up code for them? Or, I could help the Perl using populuce at large and work on neat Perl toys to help people who need to refactor code and let everyone benefit, naturally reaching beyond the confines of the company's customers and programmers? Props to Larry Wall here, for making one employer a bit better off but the whole world a much better place. Why don't we all go in with an honest assessment rather than robotically adopting the selfish interests our masters, complete with their lack of vision?
This company is re-focused on profits and creating sustainable growth -- could it be that the inherent selfishness in trying to make more and more money each year naturally and necessarily poisons the company? We're all aware of the companies that have had staying power, but we forget about those that rise and then plummet -- those that make up the vast majority of cases -- it seems like those were all killed by their own hands, not by their competition. Even Microsoft often kills their competition by forcing them to panic and most of us aren't up against Microsoft. Even those that stay have rough periods -- quality drops, they squander their brand reptuation, line extend too far, fight consumer advocacy groups rather than work with them, and generally become self-serving. Only surviving a near death re-focuses them on doing good work. Walking into this company, if I announced that I wanted to "do great things for the customer" and started plugging away at something of my own device, heckles would go up. I'd be, nicely at first, coaxed towards more pressing business needs. In a company with 12 people, where they managed to yank someone away from Hewlett Packard (back when HP meant something, before they got focused on profits and off of product), and this person came in with a knowing grin, listened to everything everyone had to say, looked at all of the code, and said, "hang on, I've got something for ya'll", and set to work, giddy tingles of anticipation would prance up and down everyones spines and re-invigorate them in their own projects. There's a whole continuum there. Momentum is huge -- everyone knows if the company is actually moving on a downward or upward trajectory -- but few people know what pressure is being exerted on its course. I suspect, just drawing from experience, that this new-guy-works-on-something-of-his-own-devicing-and-is-permitted-to-do-so
thing is a good litmus test for the force being experted on the company's trajectory. And -- holy shit -- Google builds it in, to a degree. According to my test, which I don't know if I agree with, Google is just going to go higher and higher. Could it be that, just like Henry Ford with his crazy assembly line idea, the company is going to go up, faster and faster, for at least one whole generation, merely because they figured out a better way to conduct business that no one else understands because they can't grasp logic when a force so primal and powerful as greed seems to be effective to those who don't know calculus?
I didn't ask myself this stuff at Mayo -- I was single-handled knocking down major projects of significant actual business value. I didn't ask myself this during the dot com boom as I hoped that my efforts would become significant, even though the users weren't ready and waiting, like at Mayo. Consulting, I was spread thin enough and charged little enough on each project that it didn't matter whether the users materialized or not, or whether the efforts paid for themselves or not, because the bets had been hedged so radically that it really didn't matter. With each step, I'm further and further away from actually enabling users, and, remember that I'm a cynic, this last destination seems like the farthest removed from all of them.
Previous bitchfests about SOX were less informed but apparently no less valid.
Holy crap. Writing this, it occurs to me that I'm easy pickings for the right startup. It's also occured to me that my largest fear about Google -- that all my efforts for hackery would get swalled up by work -- probably also applies in similar proportion here, where I'm at. It's been great for forcing me to learn things that I should have learned a long time ago except for blind spots I've developed over the years (which will be the next article) but the milk will be a lot less sweet after that flow subsides (yes, I will mix three or more metaphores in one sentence).
Am I just a cocky bitch for wanting to work on things of value? I don't know. Perhaps. From all of the people I know who hate their jobs, I don't think you can keep your worthless supressed into your subconcious -- it bubbles up -- and I think your own subconcious defines your self-image of who you are by what you do, and only doing things of no value (except to a few extremely wealthy executivies) ruins your life. Maybe it's pride that makes me think I'm capable of doing something of value, but I don't think that's it either because I've volunteered enough to know that even a little effort for the non-profits can go a long way, and you don't have to be brilliant to help a good cause in a way that really matters. I often tell my unhappy friends that you will never be paid to do anything truly worthwhile, and that they need to decide if they're going engage in worthwhile taskes despite. Overwhelmingly, the answer has been no -- I have two exceptions as friends. By probably no coincidence, they're also the friends I most often find myself grateful for having. I still need to make my money somewhere. Bargaining for a low salary, purely intuitively, might have been a strategic masterpiece. Maybe I can say, just a bit more often, "can't help with business emergency right now, too busy saving the free world", and get away with it, like an under-paid, overly-depended-upon sysadmin.
Thank you for reading. I hope you found something interesting in there. At the risk of changing the tone to something rude, I love insights and comments that take ideas and run with them, but I hate comments that degenerate discussions into something more basic and tired, so everyone is encouraged to read http://use.perl.org/~scrottie/journal/31900 (which is much, much shorter) before commenting.