Hugoware

The product of a web developer with a little too much caffeine

Minimize Context Switching

with 2 comments

I very rarely get to work on only a single project at a time when I’m writing code. Normally I have a couple projects going on at work plus a few extra at home. Add in a few blog posts and bug fixes in the mix and it starts to get really difficult to remember where you were at when you sit down to start working. Most people refer to switching between projects as context switching which normally has a very expensive cost in mental resources.

However, it really doesn’t have to be that way. You can minimize, and sometimes completely eliminate, the cost associated with context switching. Here are some ways I have found that has transformed my ability to work on multiple projects at once.

Minimize Complexity, Increase Clarity

Whenever I’m talking code with other beginning developers, this is the first point I start with. Complexity and clarity is one of the most difficult battles for a developer since the definition of ‘complex’ and ‘clear’ constantly changes.

Remember when reading contents a text file was difficult for you to understand? Now you can write an entire content management system in a single lambda expression. The perception of complex code diminishes over time for a developer but complexity of code never changes (too philosophical?)

The point is that just because you can understand large chunks of code doesn’t mean that it isn’t complex. Large blocks of code require a lot of time to read and comprehend, even if they are well documented — which adds significant context switching costs. Here are a few of the main points I like to discuss.

  • Always use clear names for classes, functions and variables — You’ll never regret naming a function employeeTotalSalary instead of just x
  • Keep functions short and specific. Limit the responsibility of a function to a single purpose. If you have a function that has multiple steps, then it ought to be in its own class.
  • Using named enumerated types as a return value from a function are often more clear than other responses such as booleans or nulls.

Be Consistent

Another point is to keep the way you code your project consistent. If a style of an project changes from class to class and function to function, then you can expect the cost of context switching to be dramatic.

For example, what if you chose to return ‘null’ in functions that encountered an error — but for only half of your project. Then, the other half of the project you threw exceptions. Each time you opened that project you would be forced to read code and remember all of the little details for each class and function you were working with.

On the other hand, if you were consistent with your approach, then after the first error you encountered you would remember how to deal with the rest of the project without needing to open a single file.

  • Be consistent with your approach to handling errors, passing arguments, cleaning user input.
  • Remember the ‘DRY’ Principle — Repeated code leads to inconsistent code. If you’re doing it more than once then you need to move your code into a single, well named function.

Test Driven Development

I’m not a huge advocate of Test Driven Development – I don’t think it solves nearly as much as many people suggest it does. There is a lot more to if an application is working than a series of tests can prove (for example, a website and browser rendering issues). However, TDD can go a long way to make you confident that your changes aren’t breaking existing functionality.

Because a single change could potentially break an entire system, you can’t just modify some code and then hope for the best. Instead, you have to spend a lot of time reading code and finding possible errors and then testing them.

Even if you aren’t an expert at the methodologies behind TDD, using Tests in a project is a great way to minimize the context switching costs. You can focus on making a change and verifying that you didn’t break any existing functionality.

  • Using tests is a good way to minimize context switching because you don’t need to understand the project to make a change.
  • You don’t need to be an expert to write tests — Just spending an afternoon researching TDD can go a long way

Don’t Stop Here Though…

Context switching is a difficult thing to deal with, but reducing complexity and improving your confidence in a project is a great way to make switching between projects easier than before.

These are just a few ideas that I wanted to type about tonight. I have a lot of other suggestions that I share with developers that I’ve learned over the years. Additionally, there is a lot of great information about managing code complexity on the web.

If you aren’t doing anything to reduce the complexity of your projects then you can always expect your context switching time to be a difficult transition — but the good news is that it doesn’t take much to reduce that cost and make your life easier.

Advertisements

Written by hugoware

December 28, 2009 at 12:19 am

2 Responses

Subscribe to comments with RSS.

  1. Context switching is very prominent this year, as with reduced staff and budgets we find we’re doing a lot more with a drastically less resources. It has forced us to focus on the necessary and the sufficient. One thing that has helped is using design patterns, and the command pattern in particular. This has made extending our apps functionality much easier.

    Believe it or not, relying less on ViewState and implementing more client side functionality with jQuery has really boosted our productivity. We’ve used John Resig’s micro-templating function with WebServices for our workflows, which has allowed us to have one aspx form for workflow task editing. We can handle variation in the data for each task with the templates. Basically we keep the templates stored on the server and the form uses a $.get() based on type.

    In these times being able to work on one thing is a luxury, but sometimes you can do your best thinking when under the gun.

    ActiveEngine Sensei

    December 29, 2009 at 6:48 am

  2. I forgot – jLinq has also made a difference this year as well!

    ActiveEngine Sensei

    December 29, 2009 at 7:06 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: