Paul BecotteAdmin

Deciding What To Do Next

Harder Than It Should Be

I've been coming across a problem a lot lately. I have some problem, and there are a couple different approaches. There's one that could get us through the day, and there's one that will be a better solution but will take some work. So the naive way (the way I always do it) is to try and guess how big the two solutions will be, and do the simple one if the bigger one is a LOT bigger, and otherwise do the full solution.

The problem is with estimates. I have very recently had serious issues with the estimates going both ways. In one case, we had been putting off setting up Redis replication for a while. We knew it would drastically speed up our application, but it seemed like a big job and there were always other ways to patch things up to keep performance acceptable. We talked about replication off hand for months.

One day I finally went ahead and did it. Turned out that it took less than a day, and the payoff was much greater than expected. (A typical web request is firing ~14 redis requests and using 24ms for those. After the replication was set up, those 14 requests I have seen as low as 2ms). It felt silly to talk about it for so long and then when I actually tried it have it go as smoothly as that.

On the other hand, there have been plenty of cases where I went ahead and did the big project and it wound up being much harder than expected. The problem here isn't that it took longer, since the expectation is that it would have had to be done anyway. The problem is that I came up with another, simpler, better solution down the line.

It's hard to predict the future of course. But it gives me even more to think about when trying to map out my priorities.