Paging in work

Introduction

Improving FuzzMeasure to take advantage of Leopard under the hood was an exercise in patience and self-discipline. When I first learned about Objective-C 2.0, I wanted to just leap in and change every single accessor to use properties and turn for into for-each loops.

However, I didn't have the time to do this, and I was smarter than that — mucking around in code that already works isn't necessary. That said, there are benefits to ripping out code when you have the opportunity — less code means less bugs!. Also, converting to Objective-C 2.0 buys you other benefits behind the scenes, such as enhanced thread safety, proper memory management, faster enumeration, etc.

How does the one-man shop deal with balancing this lack of time with a mounting pile of important, but not time-sensitive, work? You page it in!

My method for developing FuzzMeasure is very organic — it has to be, because I don't have much time to spend on it. I start off by working on the tasks that are high-priority (features, bugfixes), and those tasks naturally lead to sub-tasks that need to get done (implement such-and-such in the foobar classes, add corresponding menu items). Maintenance tasks are also on my list of ongoing work (refactor, convert classes to Objective-C 2.0, shark-and-optimize, update API usage where necessary, etc.) This is your standard priority-based todo list workflow.

Unfortunately, following that approach strictly would only lead to the specific improvements on the tasks you're working on, since you have to slash out less-important tasks in order to ship. Users really could care less and probably wouldn't notice my use of Objective-C 2.0, or whether a family of classes are accurately describing the underlying model. I should probably give a canned example.

Adding colour to graphs

Suppose you're adding the ability to change the colour of plotted data in a graphing software package. You modify the graphed data model to store the current colour, and write that new accessor as an Objective-C 2.0 property among a handful of getters and setters.

Now you plug the setting of the colour into the UI, and move on to the next feature (after testing thoroughly, of course). You can check this work item off your list, and move on to others, which might include setting the line drawing style, for instance.

Over the years, your code will become a huge mess. Coding style changes, knowledge of underlying APIs change, your ability to refactor improves, etc. If you continue down this path, you end up with a giant legacy project that you'll feel the urge to rewrite from scratch when you're no longer able to comprehend the code.

I should know — there are three or four hunks of code inside FuzzMeasure which are currently in this state. I don't want my code to be like this, but the features they're attached to are pretty stable and rarely need to change.

I try to mitigate this problem by paging in less-important tasks that are related to the important features I'm implementing. These tasks include refactoring and Objective-C 2.0 conversion. Let's modify the example.

Adding colour to graphs, revisited

Suppose you're adding the ability to change the colour of plotted data in a graphing software package. You modify the graphed data model to store the current colour, and write that new accessor as an Objective-C 2.0 property among a handful of getters and setters. At this point, my brain starts the following conversation with itself.

“Hmm. I don't like the inconsistency here. While we're in the file, let's change all the other properties to use the new Objective-C 2.0 syntax. Should only take another 10 minutes.”

“Oh, I just remembered — we're also going to set the drawing style in a later feature. I might as well add that, too.”

This is exactly what I refer to when I talk about paging in your work. Use the principle of locality to your benefit and page in any work that would affect the area of code you're currently looking at.

Developers must keep their heads filled with information about classes and program structure while working on code. Paging that information into your brain is expensive, and time-consuming. Some developers refer to this as getting into the zone.

Once you're in the zone, modifications can happen more easily. So, when you're in the zone, and working on a file that could stand to use some extra love in the form of Objective-C 2.0-ification or refactoring, just do it. You will probably end up with a code base that's probably about 50% modern, but you'll also have a code base that ships on time.

For many of you, I'm sure that much of this isn't new, and it's all very obvious. However, I like posting about my thought process while I work on FuzzMeasure. We all think and act differently while we work, and I'd love to hear how others differ or are similar in their thinking.