Do You Like Pain?

I have a co-worker who's never happy. Never. But today it's even worse. He just lost an hour or two of his work. He was writing code that deleted a large number of files, and due to an error in the code, it deleted everything- including the script he was writing! He hadn't checked in for over an hour, so that time was gone and he has started over.

Today he's really not happy.

Why didn't he check in his code? He's not a slow developer. On the contrary, he's very smart and pretty fast. He hadn't checked in because the tools we're using at this client's site are slow. Real slow. About a minute to even open the GUI slow and there's no command line client.

The team we are working with is a little annoyed by the speed of the tool, but they've largely acclimated to it. Statements like "What we're doing is complicated. It has to be that slow," usually indicate that the Stockholm Syndrom has kicked in. After experiencing pain for so long, we start to think it's the only way. Everyone must hurt this way.

So how are you hurting? The saddest bit of news you'll hear today is this: you don't know and you can't tell. If you're in this situation, you're not able to see the pain for what it is. I've had clients who stored all their data in very large XML files, which they then zipped up, and stuffed into a database as a blob. When I pointed out that extracting these blobs to do basic searches might be the cause of their performance issues, they protested loudly. It was the best way to solve their problem. It ~had~ to be that way.

Once you've lived with pain long enough it becomes your new norm. After the first six months or so, the pain becomes your daily experience. So what can you do to break the cycle? Here are a few ideas.

Open your office to floating workers. Some companies (like Relevance ) have a resident artist program, where they invite selected, very smart individuals to come work with them for a month or two. Perhaps you could do a "prisoner swap" with another company you've got close ties with. But the idea is to bring in someone who's not acclimated to your pain.

And when they come in, listen to them. Don't dismiss their questions or concerns. In a few weeks, they may have acclimated too and you'll lose the benefit of their perspective.

You can also bring in exernal help (blatant commercial plug). Bring in a coach or a team for several weeks of evaulation. Keep them onsite long enough to get past the problems you feel you have, and let them discover what the actual problems are.

When you bring in people from the outside, be sure to listen. When they complain about how slow and clunky your source code management solution is, fix it instead of justifying it. When they point out that it shouldn't take half a man year to test a release, don't say "tut tut silly man... we ship ~enterprise~ software."

A third way is to measure what you do. Grab a legal pad, and write down everything you do all in 10 minute increments. Anything that isn't labelled "Write code", look at twice. Are you debugging for hours? Half a day in meetings? Try to look at anything that's preventing you from writing and deploying code.

There are a large number of basic software processes that do wonders on all the pain you're having, but you've got to recognize the pain first.