Controlling your emotions

I’ve been a big sports fan every since I was a young kid, and one thing that always amazes me is how much emotion plays a part in pretty much every sport. For example, in the NBA last year, the home team won 60.8% of the time. If a team were able to block out emotion on the road so that they played as well on the road as they do at home, that would be a huge advantage.

Emotions affect software developers too. I didn’t really think about this so much until I noticed how I was going about things on my current project.

I’m working on a project by myself for a company that has no IT department. So I have to do all of the requirements gathering, design, development, testing, and deployment. I got all of my requirements, I estimated everything out, and I have an Excel spreadsheet where I keep track of how much work I have done and how much I should have done by this point.

I feel like I check that spreadsheet every day to make sure that the number of days of work I’ve completed is higher than the “where I should be” number. Now this isn’t all bad, it’s good for me to know where I’m at and if I’m behind. But this obsession is leading to other odd behavior.

For example, I’ve had the server I’m going to deploy on for months and I keep putting off setting it up. I didn’t conciously think this, but setting up the deployment server wouldn’t make my “hours finished” number go up in my spreadsheet, even though I obviously have to set up the deployment server sometime. So because I wanted to bump up my “hours finished” number, I would do feature development.

A couple weeks ago, I had a couple features drag on several days past the estimate I had for those features, and that was a really hard week. Not because I was in real danger of getting behind, but I was week ahead of schedule in my spreadsheet before the week and I was right on schedule after the week (I didn’t get to cross anything off that week). I felt stressed out all week.

Why was I so upset? I wasn’t even behind schedule! In reality, I ran into a feature that took longer than the estimate, while earlier in the project I had features that took less than the estimate. It really shouldn’t be a big deal.

I realized that I am addict — an addict to getting things done. We all want to be able to cross a feature off the list, and we feel like we haven’t accomplished anything on the feature until we do so.

If you want to see what a developer under pressure, watch what happens when the amount of time they’ve spent on a feature exceeds the estimate. I’ve seen developers get extremely flustered in this situation. They get irritable, they worry that someone is looking down on their performance, and often they cut corners. And for what reason? Because of an estimate, just a guess of how long something is going to take!

An estimate should have no effect on how long a feature should take. If a feature is going to take 3 days to develop, it doesn’t matter if it were estimated at 1 day or 15 days, it’s going to take 3 days. Period. If you stop writing unit tests once you’re over the estimate just to get it done, you’re doing everyone on the project and yourself a disservice.

The addiction to getting things done manifests itself in other ways. I’ve seen situations where developers could’ve spent 5 minutes installing a tool or an update that would’ve saved them loads of time over the course of a project. But they feel like they’re too busy to stop for 5 minutes and install it, so they continue doing it the slow way. These are completely logical people making very illogical decisions.

Other people won’t take the time to learn a new tool or a new technique like TDD because they would have to slow down to learn it. Sometimes this is valid (we all have deadlines), but if you honestly think that something might be able to save you lots of time in the long run, isn’t it worth spending a couple days looking into it? It might work out, and it might not. But if it doesn’t work out, all you’ve lost is two days, and if it doesn’t work out, it might revolutionize the way you write software.

I guess my point is be aware of your emotions and how they affect the way that you work. Don’t let your emotions control you and cause you to make illogical decisions. And please remember, that an estimate is just that — an estimate!