Archive for September, 2009

The interruption hierarchy

Wednesday, September 16th, 2009

If you work with people, and you probably do, you can rest assured that you’ll be interrupted from time to time. Sometimes, hopefully rarely, there will be multiple interruptions at the same time. This article shows how you should prioritize those interruptions to maximize your productivity.

The order (or interruption hierarchy) in which I process interruptions goes like this:

  1. In-person visits
  2. Phone calls
  3. E-mail and Instant Messaging

In-person visits

The in-person visit, or “walk-up” is when a co-worker visits you in person. This should receive the highest priority, as someone has taken the time to actually get up from their seat, and walk over to see you. They have taken the initiative to ask a question or resolve an issue using direct communication, the most productive way to do such a thing for both parties involved.

This is the source of one of my greatest pet peeves in a retail context. There have been times when I’ve visited a store (the “bricks and mortar” type, as the e-commerce crowd calls it), and will be in the process of finalizing a sale when the clerk drops everything because the phone rings. I’ve taken the initiative to come in to the store and really buy something, with real money, but I’ve been put on hold because a perspective customer, who may or may not come into the store, is calling. Take care of the for-sures first, then move on to others.

Phone calls

There are times when a co-worker cannot stop by because they’re not physically located in the same area as you. Sometimes they may be in an adjacent building, in another city, or they may have a position that requires them to travel. For those types of people a phone call is the most productive way of fostering communication, and you should extend a high priority to them. But for others, a phone call is not as good as an in-person visit, but better than non-verbal communications.

However, if you have an in-person visit occurring when your phone rings, let the phone go, regardless of who it is. That’s what voice mail is for. Do not interrupt the tempo of your current conversation by starting another.

Email and/or Instant Messaging

Unless the sender is in a remote location, I assume any email or IM communication is low priority. For a local (i.e. in the same building) co-worker, the only time I find that email is acceptable to start a conversation is when there may be background material necessary for the conversation (Example: sending a specific error message or stack trace, then stopping by to ask about why the error is occurring). Other than that, I view email useful only for ‘follow-up’ messages, or low-priority questions that do not require an interruption, and that can be answered at the addressee’s convenience.

Do not fall into the IM trap of confusing “Instant” with “Important”. If you find yourself stopping whenever an IM window pops up, regardless of content, consider closing your IM client. Chances are that most of the IM’s you’re receiving aren’t worth the time and thought lost by looking at them.

Obviously this changes if either of the two people involved in the communication are working off-site, perhaps telecommuting. However, I’d still prefer phone (or other voice communication, such as Skype) over email and messaging.

Managing your interruptions

A friend once told me of a co-worker that has implemented office hours, much like college professors do. During those hours, the door is open, available for anyone to drop by, ask questions, general chat, etc. However, once office hours are over, the door is shut, and it’s heads-down work. If you could possibly get by with that in your workplace, I’d suggest it. It almost requires an office; I find it hard to ‘shut the door’ on my cube.

Look into creating a “Do Not Disturb” sign policy at your workplace. In order for this to work, you’re going to need buy-in from management. If you get that, and the policy is adhered to, then you can implement at type of “office hours” policy. However, the system cannot be abused; you cannot simply leave the DND sign up all day, everyday, and expect people to respect it.

If you get to a point in a in-person or phone interruption in which you’ve either resolved the issue or reached a point where a consensus cannot be reached, you’ve got to make a move to get the conversation to wind down. In the case of the resolved issue, just repeat the consensual conclusion, and thank the co-worker. If they still don’t leave, politely mention that you need to move back to the work you were doing earlier. Typically, interruptions that reach a conclusion won’t keep going endlessly; however, those interruptions when a consensus cannot be reached can be tricky to end. Tell the co-worker that you understand the issue and will need some time to think about it, then schedule a follow up meeting. Be sure to schedule this meeting immediately to assure the co-worker that they’re not just being blown off. If that doesn’t end the conversation, try the same approach as with the conclusion scenario: tell the co-worker that you’ve got to get back to your original task, and that you’ll follow up shortly.

Enforcing XHTML tags in a JSP template

Tuesday, September 15th, 2009
For those of you that don’t know me, and most of you don’t, I’m a very compliance-based person. I love standards and writing code to meet or exceed those standards. In the world of web development, we have a great set of standards that detail how web pages must be laid out, and we even have excellent free tools to ensure that our HTML, regardless of how it’s generated, is compliant to the W3C standards.

Imagine my horror when I ran a validation check against a JSP/Struts project using XHTML, and found that it failed. I still tear up a bit when I think about it. There were several failures of certain tags not being properly closed. To make debugging matters worse, not all tags were exhibiting this problem.

The problem centered around <input> tags not being properly terminated. In XHTML, all tags, including those that do not have body contents, must be closed. A tag without a body should close itself (i.e. <input />). Looking at the generated HTML source, I could see that tags generated by the Struts html taglib weren’t being closed.

Typically this means that the page was not declared as XHTML; this is done by using the <html:html> tag with the xhtml attribute set to true. I looked at the JSP, and confirmed that the xhtml attribute was in fact set. When that attribute is set, the Struts taglibs are supposed to create XHTML-compliant code. In this case, it was not doing that.

I started looking around various Java and Struts web sites, looking for people having the same issue. If I did find a similar issue, it was due to a defect in very early releases of Struts, and was not applicable to the release I was using. I then started looking at the Struts html taglib documentation to see if I was using the <html:html> tag correctly, when I found the documentation for a similar tag, <html:xhtml>, which contained this pearl of wisdom:

Using this tag in a page tells all other html taglib tags to render themselves as XHTML 1.0. This is useful when composing pages with JSP includes or Tiles.

Not only am I compliant, I’m big on code reuse, which means using templates that use the aforementioned JSP includes. It turns out that the <html:html xhtml=”true”> tag does not apply to JSP’s that are included. To fix the problem, the <html:xhtml/> tag had to be placed at the start of all included files.

Then compliance nirvana began.

What is productivity?

Sunday, September 13th, 2009

Welcome to the first in what could be well over two articles on a matter of great importance and interest of mine: Productivity. Here I plan on giving my advice on ways to improve your productivity, based upon ideas of others that I’ve found useful, as well as ideas of my own. I am a software developer, and as such, will relate these articles to the discipline of software development. And yes, I just used the word “discipline” near the phrase “software development”.

The motivating factor in starting this series is that I used to work at one of the most unproductive companies I’ve ever seen. They spent over three years working on a project that shouldn’t have taken more than one year to complete, and weren’t close to a true ‘beta’ (i.e. complete functionality) when I left. I do not have answers to all of the productivity problems at this company, and by writing these, hope to force myself to find some. Prior to starting, however, I need to define what productivity is.

There seems to be confusion as to what productivity is, and how it’s measured. In my world, productivity is the measurement of how much you do in a given period of time. Specifically, the American Heritage Dictionary defines it as:

The rate at which goods or services are produced especially output per unit of labor

However, I will quite often hear something to the similar reported on business news outlets:

XYZ Widget Company reported an increase in productivity for the just ended quarter, thanks in part to the shift to a 10 hour work day.

Sorry, but that’s not an increase in productivity. It is working harder, not smarter. Let me explain a few reasons why I believe this is not an increase in productivity, and may actually be a decrease.

Let’s look at the fictional XYZ Widget Company with the assumption that they produce 1.2 widgets an hour. Over an eight-hour workday, that’s 9.6 widgets a day. If XYZ announces a 20% increase in productivity, it would mean they are creating 12 widgets a day. But if that day extends from 8 hours to 10 hours, itself a 20% increase, that washes out the productivity gain. XYZ is still creating only 1.2 widgets per hour.

To make things worse, if XYZ is a union shop, and the workers get paid 1 1/2 times their normal salary for those last two hours, it means XYZ is spending more on labor, which means XYZ is getting less for their money, another way of saying productivity at a company level declined.

It only gets worse from there. If the creation of widgets is a manual, human-based process, you have to factor in that as humans tire toward the end of the workday, and produce less as they get tired, which means that not only is XYZ paying more for labor, but they’re getting less in return.

Now let’s assume that the widgets that XYZ is producing is actually a software product. The longer software developers work, the more defects (sometimes called ‘bugs’) are injected into the software. These defects must be fixed when found by QA, meaning the developer has to stop the new task they’re working on to fix the old task they did not properly complete. Not only does that add development time (and thus reduced productivity) to the old task, it delays the new task.

To put it simply, working more hours does not mean an increase in productivity, and usually means just the opposite.