This company I'm at is having trouble hiring people, and they've even taken to hiring telecommuters and advertising the fact. Still, we've had four people leave in my small group in the four months I've been here, leaving about six. The hemmoraging is bad.
This is a company that tries extremely hard to provide that nuvo happy work experience. We don't have barristas like Google does, and there are no company provided Segways, but we have free lunches including take-out from area resturants, pretty flexible hours, telecommute options, and a low stress environment. The programmers are not hounded.
So, what's wrong? That's a matter of opinion. Here's mine.
Management is too organized. Perhaps they're smart or experienced, but try to account for the work capacities of each programmer, use "agile methods" to maximize each programmer's productivity. There are scrums, release schedules, three kinds of releases, and tons of release planning meetings. The net result is that programmers aren't free to do what needs to be done without a massive political struggle trying to break out of the boxes we've been put in. No one told these people that programming is solving hard problems (or else someone would have done it already), so they expect to be able to run the process like clockwork when really it goes more like a baseball play -- lots of ad hoc, impromptu scrapping and problem solving using every available resource. I fear the consequences on myself of other people leaving -- they'll try to make more "effective" use of my time. The work environment is politically opressive. It's hard to notice as the political lines are so firmly drawn that it doesn't feel like there is a battle, but there is one, and the engineers are hopelessly on the losing end. Organized management, where the management plays the role of the process expert, is fantastic for non-skilled or low-skilled tasks like (building) construction and fast food, but it's exactly backwards for managing technical people. When managing technical people, it's the workers on the bottom of the org chart who are the experts, not the management itself. In our case, one of the resignations was because technical metters were being defered to the top in a case where the top really wouldn't or couldn't comment usefully, and the other because the release process was made insanely complex and yet ineffectual in attempt to satisify management's ideals, robbing the whole department of energies better spent on code. Agile management is micromanaging from a distance.
The company is going corporate, but they think that's okay because they're really not like that, they swear. If everyone else hates it to, why can't we all revolt against it? You don't do something bad, apologize for it, do it again, apologize, repeat indefinately, and have it be okay. It's not okay. If you're the sort who runs companies, "corporate" might even sound like a good thing. Back to the baseball play example. How well would you corporate rigamarole, with request queues, several layers of management, committees, etc, etc do in a baseball play? They'd be all over themselves for a week doing something with 100 people that one person should have done in seconds. To the programmer, who faces daunting technical problems, adding in beuorcracy makes the problems insurmountable. We've got hundreds of thousands of lines of code and more possible program states than there are atoms in the known universe, and yet our major frustrations all come from problems that are social.
Short-term fixation. Public companies all implode due to this. They find themselves without a functioning R&D department because they cut people to make profit projections and R&D has no immediate return. They do things that are down right abusive to their customers and employees -- eventually -- in order to make numbers for their shareholders. And when it comes to code, they take the approach of what features can be gotten online next week or next month but utterly, completely avoid any discussion at all about what has to be done to keep the code running in a year, or in two years, or five years, or ten years... it's already been ten years and the technical debt is likely more than the company can pay off. There's a cliff and we're heading for it... Programmers do not function well in an environment where things are bad, technically speaking, and there's no indication that any time will be budgeted for making them better. We all do skunkworks projects to refactor and clean up, but when you're at odds with management over that, looking like the bad guy because you aren't cranking features out as fast as their predications suggest, you really, really want, more than anything else, to go to a place that has a clue.
Money. Programmers don't ask for money. See the previous point. We want more than anything else to work somewhere where people "get it"... where you're not trying to explain solar movements to a frightened monarch that uses diety worship as a beating stick on his subjects and already assigned symbolism to the celestial bodies. But often we figure (often correctly) that that place that's trying to lure us away from our current employer is just as bad as where we're at. But if they're offering more money, it makes it easy to justify the energy in finding out. So, programmers probably won't come asking for money, but you damn well better heap piles of it on them anyway just so that you've done it before someone else thinks to. After they've already been with you for a while is the perfect time -- you already know whether they're dedicated and whether they get along.
More and more I'm finding places don't even want programmers at all -- they want a class of computer professional that doesn't design things and doesn't build them so much as they assemble them. There are a lot of parts out there, and a lot of interest in the parts because it enables this. It's the same force -- "what if I didn't have to deal with these difficult programmer types, who keep wanting to waste company time refactoring and writing tests?" -- that makes companies go out and plunk millions down on dead-end 4GL systems that supposedly optimize programmers away. Management shows signs when it starts thinking along these lines, and the programmers start trying to figure out how to get out before things get really bad -- they're forced to use 4GL builders, or else Java goons come in and build the whole site out of componets. So, management even starting this direction creates a vicious downward spiral with the programmers bailing.
And, just for the sake of completeness (I've said this before and I'll say it again), programmers paint themselves in a corner. Perhaps the main reason programmers job hop is that their employees get used to a very rapid pace of development, and the programmers get used to being able to offer that, and then the system gets way too big and complex to easily add on to, and it would take a lot of time to really clean it up, but the programmers just can't find a way to explain that they neglected this important task and were operating on barrowed time, so they distance themselves from the whole project and go somewhere else and start making a mess there. I suggest to management that they allow for refactoring even if programmers don't, encourage them to make time, and voluntarily refocus efforts off of new features and on to architecture improvements now and then, especially if development is showing a trend towards bogging down.
Comments welcome conditionally -- please read http://use.perl.org/user/scrottie/journal/31900 first.
-scott
Re:So
Alias on 2007-03-29T12:55:52
> or else Java goons come in and build the whole site out of componets
Hmm, I'm a CPAN goon that comes in and builds the whole site out of components:)
I keep saying this over and over again, but in the long run I find the only way to create large amounts of functionality over a period of time is by pretending that it's all eventually going to end up on CPAN.
I can skimp on the docs a bit (as long as the POD's there for the primary APIs) and I can skimp on the tests a little if I have suitably thorough empiric-type practical test scripts and become a perfectionist when it comes to regression tests.
But the basic structure of making most or all functionality as a CPAN-like distribution does seem to be the only way I can avoid the debt.
And once I got into that rhythm I've found I can generally found that it's not TOO hard to sell to management that it's better that we build most or all code in reusable "components" so that it can be used by people for other projects.
It takes longer the first time, granted, but there's no second time, and you can maintain development at a reasonable pace indefinitely.
