They were like spectators. You had a feeling they had just wandered in there themselves and somebody had handed them a wrench. There was no identification with the job. No saying, “I am a mechanic.” At 5 P.M. or whenever their eight hours were in, you knew they would cut it off and not have another thought about their work. They were already already trying not to have any thoughts about their work on the job.

— Robert Pirsig, Zen and the Art of Motorcycle Maintenance

We had a manager’s meeting today on the subject of employee recognition. The text we were given to read in preparation for the meeting was indistinguishable from a handbook on training your new puppy:

Behavior which is reinforced is usually repeated. . . . You risk extinguishing the positive behavior by not recognizing it. . . . Provide compliments in a timely fashion, as soon as possible after the event occurs.

That seems demeaning to me and it trivializes the work. I like to be recognized as a person who does good work but I also want to be recognized as someone who cares about his work. I know better than anyone when my work is good and when it isn’t. I’m not looking for pats on the head.

I said in the meeting that I’d rather try to motivate people by giving them the opportunity to do great work, to have some choices about what that work is, and to become the person they’ve always wanted to be.

I pointed out that we’re giving up our youth, our family — everything we hold dear — to come in to work every day, and if the work isn’t worth doing well for its own sake, then it’s a pretty poor exchange.

“We come to work to make money,” Manager A said, as though explaining something very obvious.

“We should sell off our lives one day at a time to the highest bidder?” I asked. “That seems like a good idea to you?”

“Do you really believe the things that come out of your mouth?” Manager B asked.

Manager C stated that in “the real world,” 99 percent of the people he knows are working their jobs for the money and, financial considerations aside, would rather be doing something else with their lives.

The highest-paying job I ever had — before or since — I quit after eight months. I didn’t have another job to go to; I just hated going in there in the morning and I couldn’t wait to go home in the afternoon. I never got a chance to do anything I enjoyed or anything I was good at.

I’m not doing this stuff to get rich. I am a programmer.

Thus spoke The Programmer.

For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done.

Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?”

Ummm, I could, but it wouldn’t contain any additional information than what’s on the board.

That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task.

It never occurred to me that if you record information on Post-Its and stick them on a wall, rather than recording the same information in an “official” format like Excel or Project, there will be people who assume that you’re just screwing around.

NB: It’s not their fault for not getting it; it’s a communication failure by me because I didn’t anticipate the situation.

Thus spoke The Programmer.

I saw a guy yesterday — let’s call him Jack — that I used to work with 20 years ago on my first programming job.

My most vivid memory of him is the day he offered to sock another programmer — let’s call him Sid — “right in your f^$&ing face, Sid” because Jack was unhappy with the quality of Sid’s work.

You rarely see that kind of passion and zest in the workplace anymore . . .

Thus spoke The Programmer.

The graphic on the right came up for discussion at the office today.

The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons.

1. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad.

2. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.

I’d just finished reading another tiresome “why oh why aren’t there more women in IT?” article when I found a former colleague on LinkedIn . . . he lists his job title as “Analyst, Software Quality Assurnace.”

Would you hire him as a QA guy? I wouldn’t, and that’s even before I saw how he misspelled “Assurance.”

The IT “profession” is chock full of idiots like this. Why anyone thinks women are missing out on something if they don’t work in IT is a total mystery.

If I had a daughter, I would tell her to be a meeting planner or a flight attendant . . .

Thus spoke The Programmer.

We’re discussing whether our organization will use a popup user survey on our web site . . .

“I propose doing the survey without the popups,” I say. “That’s why browsers have popup blockers, because people don’t like popups. A popup is like a poke in the eye. I don’t like it when things pop up unexpectedly and poke me in the eye. Whenever that happens, I make sure not to go back to that place anymore.”

Unfortunately, no one picks up on the “popped up and poked me in the eye” motif because I was then going to chide them for their junior high school mentality.

“I had a teacher who used to say that,” a young woman says. “‘It’s better than a poke in the eye with a sharp stick.’”

I say, “I used to work with a guy who said, ‘You can’t beat that with a sharp stick.’ Why would the stick have to be sharp if you’re going to beat someone with it? You’re really just looking for something with a little heft to it.”

The same woman says, “I had a boyfriend who used to say, ‘You’re not going to hold that over my shoulder, are you?’”

“You have abysmal taste in men.”

I wasn’t able to persuade the team to abandon the popups. The argument in favor was that a lot of web sites use popup surveys so how bad can they be?

I worked for a dot-com consulting company during the boom and bust of that industry. The whole thing was based on the notion that everyone else is doing it so it must be a good idea.

The subsequent implosion of the entire industry disproved that theory rather dramatically.

Since then, I try to stay open to the possibility that even though a lot of people are doing something, it still may not be a good idea . . .

Thus spoke The Programmer.

I’m reviewing my year-end Benefits Summary at work . . . I’ve got life insurance plus supplemental life insurance at a multiple of my annual salary.

I’m having a Willy Loman moment where it seems like after all the highways, and the trains, and the appointments, and the years, you end up worth more dead than alive . . .

Thus spoke The Programmer.

I had a great meeting today — eight women plus myself.

That’s not why it was great though.

These ladies want to launch an online Education Room with webinars, a speaker directory, announcements of upcoming events . . . they have none of the content ready . . . and they want to launch it on Jan. 1, 2009.

So instead of talking about how they’re planning to get the content to me so I can build the thing, they’re saying things like, “When you hover over a webinar link, it will display a description of the content — like on Netflix . . .”

Netflix. Right. So I say, “You’re not gonna get that.”

Oh, they loved it! They laughed and laughed. They knew it was ridiculous, they just wanted someone to tell them it was ridiculous.

Women love a masterful man who’s good at his work.

Thus spoke The Programmer.

I’m going to start declining invitations to meetings that have

1. vague goals;
2. a long list of invitees who don’t know how to come to the point;
3. a moderator who doesn’t know when to cut people off.

Thus spoke The Programmer.

I hold in my hand a 63-page requirements doc . . .

We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc.

Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project.

So why did we create all these incredibly detailed documents in the first place?

We have a vast collection of well-documented ignorance . . .

Thus spoke The Programmer.

My first 10 years in the software business, I had great managers. They did the management thing and I did the programming thing and we got great results together.

Then, after the dot-com boom torpedoed industry hiring standards, I got tired of working for managers who should not have been allowed anywhere near a software project, people who were not fit to direct a professional software developer to a table at the Olive Garden, much less direct their activities on a complex project.

I couldn’t possibly have continued to work for people like that — it just made a mockery of all the work I’d done over the years to actually learn something — but I still miss being a developer . . .

Thus spoke The Programmer.

I work with a company that has the following set of milestones in its standard project methodology:

• Vision/Scope Complete
• Requirements Complete
• Design Complete
• Definition Complete
• Build Complete
• Test Complete
• Rollout Complete

I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late.

Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time.

But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed.

This is a very high-risk approach to software projects. Deferring testing to the end of a project guarantees that if your project fails for any reason — and if your testing is honest, there’s always some non-zero probability that it will fail — you will have already invested in the entire cost of construction.

That’s why the history of software engineering is littered with big-ticket disasters. You never really know what you’ve got until the end, after you’ve spent all the money.

It’s also a good argument for iterative, incremental development. If you have to deliver working software early and often, you can’t fake it.

Thus spoke The Programmer.

An ironclad but widely ignored law of software development — you could probably substitute “product development” as well:

Customers never understand how something is going to work until they see it in action.

Thus spoke The Programmer.

IT has got to be the world’s most unprofessional profession . . .

I’m sitting through a dry run of a presentation for our CEO, explaining why the company’s flagship IT project has taken so long and cost so much, with no end in sight.

It seems that, compared with two years ago when the project started, headcount is up 60 percent, sales volume has more than doubled, the product mix has changed significantly, as a result of of which, requirements and assumptions have had to be constantly changed.

Of course! Two years ago, who could have anticipated that the business might look a lot different two years down the road?

If you said “Uh, pretty much anybody,” you’re right.

Thus spoke The Programmer.

When you’re meeting with the people responsible for a company’s software development process being the way it is, any suggestion that it could be improved is going to be a tough sell.

Prepare to hear something like this: “We didn’t get where we are today by doing things wrong.”

Thus spoke The Programmer.

Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition.

To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million.

At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority.

This reminded me a lot of an article I read a few days ago:

What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher priority, but every line of code they don’t write is another line that can’t break!

OK . . . you could make a case that waterfall “worked” here — clearly if, after 18 years of effort, people can’t even define the project, that sounds like a project that has no chance of success and shouldn’t be attempted — but it worked at a cost of $2.5 million.

That doesn’t seem very efficient.

What I find is that if you put the customer, the technical team and other appropriate representatives together for as little as four to eight hours, à la a Sprint Planning Meeting, it should be obvious whether or not anyone understands the problem well enough to go ahead and attempt a software solution.

Thus spoke The Programmer.

This is an excerpt from a job posting for a Sr. IT Project Manager:

• Develop project plans and ensure that deadlines are met on time and projects are delivered within budget constraints. You will use standard project management tools to define requirements and track project status.

• Manage and prioritize projects for the division using standard project planning methods and software through all phases of the project/development lifecycle.

OK, let me get this straight: You want projects delivered on time and within budget — you don’t mention whether or not you want the software to actually work, but I assume you do — and you want it done with standard tools and standard methods.

It may have escaped your attention, but that is not a standard result. The standard IT project is either late or over budget or fails to meet customer expectations, or all three.

If it were possible to deliver high-quality software on time and within budget with standard tools and methods, then everybody would be doing it.

So you want someone to achieve exceptional results — non-standard results — with standard tools and methods. How is that supposed to happen?

I can deliver exceptional results, but you have to let me do it my own way. If I have to use the standard tools and methods, I’ll get the same crappy results everyone else gets.

Thus spoke The Programmer.

My boss’s boss resigned yesterday.

If I had to sum him up in one sentence, I would say — and I think he would take this as a compliment — that he made Machiavelli look like a goddamn amateur . . .

Thus spoke The Programmer.

You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . .

Who has built something that their customer will certify is part of what they want? That’s interesting.

Who has shipped something to their customer and the customer is using it? That’s very interesting.

— Ron Jeffries

We don’t have the money, so we have to think.

— Ernest Rutherford

Ernest Rutherford was an illustrious scientist — the 1908 Nobel Laureate in Chemistry, and the father of nuclear physics.

His humble upbringing as the fourth in a family of 12 children in rural New Zealand influenced his approach to science, as summarized in the above quote.

A recruiter called me today about a job managing an $80 million IT project.

How in the world can you spend $80 million on an IT project?! I could put your company logo on Mars for $80 million.

Most of the big, expensive IT projects that I’m familiar with, there really was no reason for them to take so long or cost so much. A lot of time and money could have been saved with some upfront thinking.

I get a lot of this now — recruiters asking me if I have experience managing multi-year, multi-million dollar projects, as if there’s some competitive advantage to be had from spending huge sums of money over long periods of time.

A modern variation on Rutherford’s famous saying might be: “We’ve got 80 million dollars! Why should we have to think?!”

Thus spoke The Programmer.