Archive for September, 2006

A software project is code delivered at a specific point in time

September 30, 2006

Steve Yegge has posted this rant called “Good Agile, Bad Agile” that I’ve seen posted a couple of places, and there’s over 100 comments on it, and it’s just a steaming pile.

It’s hard to discuss the article, because Yegge’s just painting broad strokes to be outrageous. His saying “Take Pair Programming, for instance. It’s one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let’s face it: nobody does it.” is no different than a bad standup comedian saying “And what is the deal with these bad women drivers?”

The key to his “good agile” is removing the ability to know when a project will be complete as in:

You don’t need “war team meetings,” and you don’t need status reports. You don’t need them because people are already incented to do the right things and to work together well.

So the project gets done as fast as it can, but the customer for the project has no idea when that will be.

He calls this the “tyranny of the calendar”, and how open source projects don’t have them, as if that’s an endorsement. That’s true that most open source projects don’t give dates, and in at least one case, it can be damaging to the project to not be able to have dates. I’m thinking specifically of Perl 6. I regularly get email to the Perl Foundation email address asking when Perl 6 will be done. I don’t have an answer. I have customers for Perl 6, publishers wanting to write about Perl 6, etc, and I can tell them nothing more than “I dunno.” Those are lost customers.

But Google doesn’t need dates, because “Google isn’t foolish enough or presumptuous enough to claim to know how long stuff should take.” That’s because they are big enough that they have that luxury. A late project won’t hurt them. How many of us elsewhere can afford to tell a customer that “we’ll be done with it when we’re done with it?” I count maybe Microsoft, and probably not even them entirely.

For us in the real world, a project is not about a chunk of source code, but a chunk of source code delivered at a specific point in time.

Your second most important relationship

September 3, 2006

As I sit here on this Labor Day weekend, I ponder who it is we labor for. I want you to as well.

Most of us in the computer industries are lucky enough to be doing what we love. Programming, system administration and the like are in our blood. We’ve done it as a hobby, and now we’re getting paid relatively large amounts to do it. Plenty of other people don’t have it nearly as good as we do.

And yet, so many of us are unhappy with where we’re at. We work with jerks, or the companies we work for have Mickey Mouse rules that treat us like children, or even worse, hourly workers. Maybe you’re in a company with motivational posters on the wall where you can’t miss ’em when you have to take a leak. It’s a sort of ongoing battle for your soul, where the day-to-day grinds down at you and makes you miserable over time.

Seems to me, however, that the most common source of bad jobs is having the bad boss.

I had lunch with my friend I’ll call Bob who had just been let go from his job after a short, confusing month. His boss was vague in expectations, yet also a micromanager. He’d demanded on Wednesday that Bob have a project done by Monday morning at 9am, because it was Crucial To The Company. On Friday night, after Bob returned home from a long-planned dinner with his wife and some friends, he found in his inbox on his return a note: “I see you logged off at 6pm, this project is crucial to the company.” The boss badgered him all weekend until Bob finally declared that his work was done on Sunday.

Add to this that even though Bob had the work done, there were other unspoken, unmet expectations. The boss rattled them off to Bob at his summary firing, but Bob didn’t understand them after the fact.

I offered “It doesn’t sound like much of a loss. Your boss was crazy, or stupid, or just a bad boss. He wasn’t like that when he interviewed you, was he?” Bob replied “I’m glad you think he was a bad boss, because I kind of picked that up in the interview.”

Now here’s what astonishes me. Here’s a guy who’s a good programmer, who works hard, and yet he’s willing to take a job with someone who he strongly suspected of being dumb and/or crazy.

Bob’s not the only one, of course, or I wouldn’t be writing this. I’ve got other friends who jump into a job relationship hoping for the best, and coming out miserable. Some people may be desperate and have no choice, but it happens so often, that can’t be the case most of the time.

I suspect that most people miss that word “relationship”, because it is exactly that.

Your job is a relationship.

It’s a relationship with your boss, yes, but it’s also a relationship with the company, with your co-workers, with the commute, with everything that goes into your job.

It’s a relationship that you spend 40+ hours a week on. How many hours a week do you actually spend awake with your spouse? Probably a little bit more than that, but it’s roughly the same in size.

The relationship with your employer is as important to look at as the relationship with your spouse. That means both before and after you commit.

I’ll write more about this in weeks to come, as I work on my upcoming book, Pragmatic Job Hunting.