Posted On: 2020-04-27
I recently ran into a bit of a snag in my software development; one which, upon closer inspection, I should have seen coming. After a small retrospective about it, I feel that I better understand what exactly went wrong, and why it caught me by surprise (leading to a delay in my plan.)
When applying existing code to solve new problems, one will (generally) fall into one of two camps: optimism or pessimism. When optimistic, one will expect that it will be possible to solve the new problem with few changes, and that the whole endeavor will be faster than if one were building a new solution from scratch. In contrast, when one is pessimistic, one expects that the code will not be able to solve the problem as-is, and that substantial rework (possibly including a complete re-write) will be required.
In general, being accurate in one's optimism versus pessimism is optimal for planning: if one accurately anticipates how much effort something will take, the plan will be better. Unfortunately, when one is inaccurate about which of the two is appropriate, the impact of being a wrong optimist is often far worse that being a wrong pessimist (it is generally worse to experience delays than to have extra time.)
There are a variety of approaches one can use to try to control for these factors. One, the eternal pessimist, is to simply assume the worst all the time. Using such an approach minimizes the number of delays, but often comes with the cost of increased planning rework, as anytime things work out well the plan will need to change. The opposite, being an eternal optimist, is surprisingly popular* despite its massive downsides. Eternal optimism generally gives way to repeated delays in the schedule, and can negatively affect the health of workers as they struggle to keep up with unrealistic expectations. In addition to these two extremes, there are plenty of even-handed approaches as well (Scrum's velocity management being the one I have the most familiarity with.)
The specific issue I ran into was one of being an optimist about my own code, combined with planning only a single change in advance. Specifically, as a break from writing all week, I planned a few hours of coding to get the dialogue in-engine, so that I could go straight from implementation to testing (once the first draft was done.) Unfortunately, that estimate (a few hours) was very wrong: after two days of trying to shoe-horn the dialogue into the existing systems, I concluded that I will be much better off if I dedicate this upcoming week to rewriting the way dialogues, menus, and cutscenes have their text contents stored*.
The underlying reason for estimating optimistically was fairly simple: I overlooked that I had only tested using cutscenes and menus, and not using characters. It turns out, the way the state information about a character is stored (position, health, etc.) conflicts directly with the way the text content of dialogue is stored.
The key frustration that exacerbates all of this, however, is that I'm not doing much coding right now. As such, I don't have a body of more accurately estimated tasks to balance out this one mistake. Instead, I have this single (poorly estimated) task getting in the way of completing other non-programming objectives, which were originally planned to be completed by the end of April. The one upside in all of this is that there are no material ramifications for slipping a week here.
Hopefully this is a useful cautionary tale: if you're going to be wrong about your plan, it's better to be a pessimist. Of course, you may be able to avoid being wrong if you test the right things in the first place. Above all, however, having a variety of items in a plan will go a long way to mitigate the impact of being wrong once (so long as one's estimates are, on average, usually right.)