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!
This is another reason that I am so crazy about estimating in an abstract unit of measure – typically story points.
Having real hours as an estimate just serves to make people ask the wrong questions and get in a hurry. It also makes PMs ask “why didn’t we hit our estimate!!”. The reason is always “because the estimate is wrong 100% of the time”, but it still gets asked, and gets developers stressed.
You’re right Jon, estimates are just that “estimates,” and as @Steve said “they are always wrong.”
The problem is the world we live in doesn’t see estimates as flexible time. People want to know exactly when they are going to get something and how much it’s going to cost. Then they make plans around when we tell them we thing we’re going to be done. This is why I get so anxious when I miss my estimates.
We need to help our clients see that our estimates are flexible and not set in stone.
Steve makes a great point about story points. If you have story points, you can still keep track of your velocity (“our team can complete 15 story points each week”) but you don’t have an hour estimate hanging over your head.
You mentioned that “setting up the deployment server wouldnâ€™t make my hours finished number go up in my spreadsheet.” We just started adding “internal” items like this to our issue tracker, and it has helped a lot in terms of prioritising what is most important. It’s also valuable to track prod support and fixing defects in the same place too. This way it’s in your view and you can more easily justify doing it.
Do you have a wallpaper-sized version of that Dages picture?
I am upset that I did not receive photo-credit for the picture…