L-P Huberdeau's blog

A few days ago, I started reading Software by Rob. It’s filled with great articles. There are so many, I’m afraid I won’t be able to read all of them. The first one that caught my attention was How To Burn $6,540 a Week: Indecision and Software Development. The title is intriguing and the content is well supported by sources, even thought I didn’t verify any of them.

From the article… (cut short, making sense of the example would require too long of a quote)

In our example above, the first thing the developer has to do is participate in the meeting. Elapsed time: 1 hour (more if she has to prepare for the meeting). Cost: $70.

Next, she has to stop what she’s doing, add this to her to do list and come back to it in a week. Elapsed time: 2 hours to shift gears into another task then try to remember what she was doing when she comes back. Cost: $140.

The last sentence made me jump for a moment. 2 hours to shift gears and jump to an other task? That’s way too long. Of course switching task takes a few moments to absorb the new task, but two hours is excessive. That would mean 25% of the day is lost simply switching task? No way. Does it also take 2 hours to get started in the morning?

It might just be me, but I always have multiple projects running in parallel. I work on multiple distinct systems and priorities change often. Stopping to work, completely, because an answer is required does not make sense. If the person holding the precious answer is not available, there are solutions other than waiting in the queue. E-mails have this ability to let the person answer at their convenience. While waiting for the answer, I can think of many things that can be done.

• Work on a different project
• Handle some of the accumulated user requests in the stack (understanding, analysing, documenting, …)
• Fix low priority bugs
• Update estimates

Personal organization is what allows to perform multiple things at once. If every time you have free time, you need to spend 30 minutes just to find out what is the next thing that has to be done, it’s no surprise it takes so long to shift gears. I tried multiple tactics to keep track of what I have to do. I even had a PDA for a while, which I found to be completely useless and ineffective. A simple note pad to write down all elements can work. Just add it to the list every time something new appears. Even if it’s a 5 minute job. Chances to forget something are much lower, and every time you have a down time, all you have to do is look at the next line. I know, this is far from being an impressive solution, but it works.

Things get messy when the list reaches multiple pages, with a lot of elements strike-out. Flipping pages is annoying. The next logical step is using a wiki. There is no physical page flipping, but it can still get messy after a while. A few months ago, I wrote MetaPackage for Bitweaver. It allows to create dynamic lists of wiki pages, filtered by user defined attributes.

One of my coworkers (not a developer) has to deal with nearly 100 actions at a time. He used multiple organization techniques over the years and became quite good at it. He ended up organizing the wiki in his own way and made it very effective. It was effective enough until more specific needs surfaced, such as integration with other internal applications and specific features. With his help (and other spoiled users), I eventually spent a few days developing a different tracking system. Altought it ended up having a more formal relational structure than the wiki counterpart, the final result ended up having a similar set of features.

To be effective, only a few things are required.

• The listing must provide enough insight to know what has to be done.
• Things that are waiting for information (such as an answer) must be separated from those that can be done right away.
• It must be possible to add notes or various information to the task.
• It must be quick and simple to use.

We ended up mostly renaming what seems to be a title the “very next action”. A simple one line field to describe what the very next step is for the task to be accomplished, or the element you are waiting for. It’s the primary element of the listings. A quick look tells you exactly what has to be done next. The division of waiting and working is simply to reduce the length of the list and keep away the things you can do nothing about.

Wiki pages have a serious advantage when it comes to taking notes. History is kept, syntax is simple and produces clean organized output. Even if the listing should be descriptive enough to know what to do, notes about the details are always useful. Keeping the notes a click away from the action avoids having to search for it every time it’s needed.

Simplicity is important for success. Using the system must not be a burden. Even thought it does require an effort to maintain and keep consistent, it should be as slim as possible. Users discouraged by the effort that has to be done are likely not to maintain their task lists properly.

Not everyone is organized in the same way, because not everyone performs the exact same kind of work. Find your own way to keep track of the things you have to do and you won’t have to waste 2 hours simply to shift gears.

APC has been around for quite a while. Mostly known as an opcode cache for PHP, it can do quite a few other things. Of course, this requires a certain level of control on the web server’s configuration. The extension allows to easily store and retrieve values from shared memory. A simple call to apc_store() and the value is ready to be read by an other request. Even storing the results in a file is more complex than using the APC extension.

if( !$result = apc_fetch( 'my_result' ) )
{
    $result = $dbh->query( "SELECT ..." )
        ->fetchAll( PDO::FETCH_ASSOC );

    apc_store( 'my_result', $result, 3600 );
}

The piece of code above transparently fetches the result from the cache or generate it if required, then store it for an hour. Sure, it takes a few more lines than a simple query, but it’s not that complicated. The results are terrific. I used it on a query that takes one or two seconds to execute, which is not that long, but the delay is just enough to be annoying on an intranet where users expect the page loads to be instant. With the cache, the page load time goes back to the instant level, except the first time the query is executed.

It can just as easily be used to cache queries with a parameter.

$key = "my_result_$id";
if( !$result = apc_fetch( $key ) )
{
    $result = $dbh->query( "SELECT ... $id ..." )
        ->fetchAll( PDO::FETCH_ASSOC );

    apc_store( $key, $result, 3600 );
}

I use 0 as my cache duration, which means it’s destroyed only when the web server is restarted (never, right?). Some of these results rarely change. Using a 5 minutes cache would allow to keep the data up to date when it changes, but it removes the whole advantage on an application that receives a few actions per minute only. Using a larger value, such as 1 hour does not make sense because the changes would not appear fast enough, so I decided to use infinite cache and clear it manually when needed.

The cache can be cleared manually using apc_clear_cache(), but I don’t really like removing all values at once. If I perform an operation that requires the cache to be cleared for a given set of results, I don’t want the entire cache of the application to be destroyed. I use a function that looks like this one:

function clear_cache( $prefix )
{
    $list = apc_cache_info( 'user' );
    foreach( $list['cache_list'] as $row )
        if( strpos( $row['info'], $prefix ) === 0 )
            apc_delete( $row['info'] );
}

clear_cache( 'my_result' );

Even if you don’t need opcode cache, it’s worth taking a look at APC.