Frustration

For the past eighteen months, I’ve been working for a company, which like many in the computer business, is pretty dysfunctional. This morning it reached a breaking point, and after firing off a few emails that might jeopardize my future employment there, I walked down to my neighborhood coffee shop to cool off. This is the rant I wrote to get it out of my system.

Like I said, most of these problems aren’t specific to any one company. They’re widespread. But they’re also the kind of thing that frustrated me enough that I started my own business working as a contractor to try and avoid them. Sometimes (usually on smaller jobs) I can avoid the problems entirely, and I’m a happy camper. But when I take on a longer-term contract, they seem to crop up every time, and that’s making me rethink the kind of jobs I take.

The first problem is email noise. Where I’m working at the moment (or more properly not working right at the moment), their version control system is CVS. People have developed a lot of bad habits with it, and the most common is that they’ll work on a huge number of files in the project, and then when it comes time to check their changes in, it takes a while. Thing is, this is a common enough problem in software engineering that there are a number of known solutions to the problem. The first is to refactor the code so you don’t have to touch more than a couple files to fix any single problem. But getting that refactoring done takes time, and without constant vigilance, that time can be pretty severe. The second solution is to use a version control system that has atomic commits so you can commit all the files you’ve modified at once, and not have to worry about notifying the other team members so they don’t attempt to check code out of a broken repository. In any case, they don’t do any of these things, so everyone on the team seems to send out two or three emails every time they’re checking in any changes. One to say I’m starting, one to say I’ve finished, and am about to try to compile my changes on the other platform, and a final email to say Everything’s okay. Multiply this by a dozen engineers, and it’s pretty easy to see forty or fifty content-free email messages every single day. I guess I shouldn’t be surprised that most of these are flagged as “Urgent” even when I’m receiving them the next morning and I could just as easily ignore the whole raft of them.

Email noise also happens with email that’s supposed to be company-internal. There will be notices for things like benefits meetings that I don’t need to (and probably shouldn’t) see at all. But for whatever reason, I’ll be included on the email about it, and it’s just one more thing in my mailbox that I need to deal with. When I’m working for just a single client, it’s not such a huge issue, but when I’ve got multiple jobs going (which is most of the time), it adds up to be almost as big of a total as the amount of spam I get. And it’s a lot tougher to filter out automatically. The only thing that keeps it from driving me completely nuts is the fact that I’ve gotten in the habit of setting up a new email account for each client I’m doing more than about 40 hours of work for. That at least lets me shut off the checking for accounts I’m not working on right that instant and deal with all the email at once when I’m not trying to concentrate on something else.

A second problem is a problem with decision-making. For whatever reason, they’ve evolved a system where major changes to the project aren’t decided on by a single technical lead person (which may not always be the same person), but rather any major changes have to be run past the entire engineering team. While this does offer everyone a chance to comment, it also makes for a very conservative approach to development. In fact, I find that if I follow their procedure religiously, it completely stifles any creativity I have about solving large-scale problems. I’ll think of elegant solution, which is usually incomplete. There are always details that you won’t have worked out until you’re in the code. But if you run an incomplete idea past a large group, someone will usually object and ask you to flesh out the idea before you start coding. When I try to flesh things out without getting some of the code in place I end up over-designing the solution. And once the project has been thoroughly over-designed and I’ve started implementing code, I’ll find some catch that requires me to change the design. Then it’s back in front of the entire team, often to find out that now the change is deemed too risky and I’ve got to spend time taking out my first round of changes, archiving them away somewhere, and hoping that maybe I’ll get a chance to come back to it for the next release. When the next release comes around, I have to start over by trying to get consensus for the changes again (if I’m even still working for the client). Why bother?

Another problem is conflicting chains of command. I find that I’ve usually got two or three “managers” when I’m working as a contractor somewhere. There’s the person who takes my invoices and makes sure I get paid. There’s the person who signs the contract that specifies what I’m to work on. And finally there’s the person who handles the day-to-day decision-making. Sometimes functions are combined, but I’ve never worked for a company with more than five employees where all three functions are embodied in the same person. That’s not a problem if it’s a short-term contract and everything is spelled out very clearly in the contract, but on a longer-term deal where my responsibilities aren’t well-defined, it inevitably leads to a conflict. I’ll either end up getting conflicting goals from different managers, or I’ll get no direction at all while they try to figure out how they want to proceed.

I could probably go on for another dozen pages, but that’s enough to get the bile out of my system. Time to walk a little more, grab some lunch, and see if I can get any work done this afternoon.

Copyright 2009, Dave Polaschek. Last updated on Mon, 15 Feb 2010 13:55:41.