Work Log - Particle System
Unlike my previous work on the Sound UI, my work on the particle system went smoothly.
My startup wanted to prepare the game engine and game creation tool for debut at the big Mac conference, WWDC. This meant we had only a few weeks to tackle a few glaring issues, and one of the worst issues was the particle system. The particle system was very difficult to use for beginners, layout was clunky, and several features were broken. I was given a long list of features, some of which were contradictory, some required clarification, but all of which required implementation within a week.
Rather than diving straight into the problem the way I normally do, I stopped myself and took a step back. I dug through the code to figure out how everything was wired together, between the user interface forms, the user interface code in Objective C, the particle system's hooks into the property system in Lua, and the particle system logic in C. All-in-all, this was a feature that spanned three different programming languages, two different code editors, and a user interface tool.
Big problems are intimidating. They lack structure and substance, and with prompting from your imagination, tend to take on the worst possible forms, in the same manner that moon-lit piles of clothing at night take on monstrous forms for small children.
Rather than panicking, at the magnitude of the task, I started with each feature request, and broke them down into a series of tasks. I could easily estimate tasks that required surgical changes. Tasks that required structural changes took a little longer. Rather than trying to fine-tune my estimates, I tend to stick to time buckets. Small tasks get an estimate of half a day, always. I might finish them sooner, but half a day is a good enough estimate to encompass potential complications. Tasks that might require a system rewrite take a little longer, about a day. Tasks that require rearchitecting a system takes 3 days. In this manner, I broke down all tasks into estimates of half a day, 1 day, or three days.
The benefit behind creating a task list, especially before someone creates one for you, is it enables you to negotiate acceptable completion conditions on your own terms. Your client might argue that you need to finish your work within X days, but by presenting your client with hard information on sub tasks and time estimates, your client will reveal to you that they actually valued certain features more so than others.
Another benefit behind breaking down your work into subtasks is it gives you a better understanding of the work that needs to be done, and it gives you a measure by which to evaluate your progress. The requested features were completed within 2 days, rather than 2 weeks. With time for testing and bug fixing, the total amount of work came out to about a week.
My startup wanted to prepare the game engine and game creation tool for debut at the big Mac conference, WWDC. This meant we had only a few weeks to tackle a few glaring issues, and one of the worst issues was the particle system. The particle system was very difficult to use for beginners, layout was clunky, and several features were broken. I was given a long list of features, some of which were contradictory, some required clarification, but all of which required implementation within a week.
Rather than diving straight into the problem the way I normally do, I stopped myself and took a step back. I dug through the code to figure out how everything was wired together, between the user interface forms, the user interface code in Objective C, the particle system's hooks into the property system in Lua, and the particle system logic in C. All-in-all, this was a feature that spanned three different programming languages, two different code editors, and a user interface tool.
Big problems are intimidating. They lack structure and substance, and with prompting from your imagination, tend to take on the worst possible forms, in the same manner that moon-lit piles of clothing at night take on monstrous forms for small children.
Rather than panicking, at the magnitude of the task, I started with each feature request, and broke them down into a series of tasks. I could easily estimate tasks that required surgical changes. Tasks that required structural changes took a little longer. Rather than trying to fine-tune my estimates, I tend to stick to time buckets. Small tasks get an estimate of half a day, always. I might finish them sooner, but half a day is a good enough estimate to encompass potential complications. Tasks that might require a system rewrite take a little longer, about a day. Tasks that require rearchitecting a system takes 3 days. In this manner, I broke down all tasks into estimates of half a day, 1 day, or three days.
The benefit behind creating a task list, especially before someone creates one for you, is it enables you to negotiate acceptable completion conditions on your own terms. Your client might argue that you need to finish your work within X days, but by presenting your client with hard information on sub tasks and time estimates, your client will reveal to you that they actually valued certain features more so than others.
Another benefit behind breaking down your work into subtasks is it gives you a better understanding of the work that needs to be done, and it gives you a measure by which to evaluate your progress. The requested features were completed within 2 days, rather than 2 weeks. With time for testing and bug fixing, the total amount of work came out to about a week.