Archive for September, 2009

Why I hate proxy servers

Wednesday, September 23rd, 2009

“Hate” is a strong word. It’s also a massively overused word. I avoid the use of “hate”, reserving it for the most heinous of nouns.  One such noun is “authenticating proxy server.”  Fortunately, for most of my career, I’ve managed to avoid workplaces in which these roadblocks to the Internet are used.  That is, until my current job.

A brick wall

A brick wall

There was an issue that arose recently that perfectly exemplifies why I hate the proxy server. Somehow, probably through the proxy server itself, I managed to have my account locked out.  While I remained logged in to my workstation, I could not access any resources outside the proxy server. The application I was using apparently needed access to the Internet to phone home (perhaps validating registration or checking for updates), and because my account had been locked, I couldn’t get through the proxy server. When the application couldn’t complete the call home, it decided to crash. Net result: I lost about 30 minutes worth of work.  All because the proxy server was there ensuring that I didn’t go to nasty porn sites.

A similar issue occurs with some development tools, namely Maven.  During a build, Maven checks public repositories for updated libraries used in the project.  If you do not have proxy settings just right, Maven cannot access those repositories, and the build will fail.  Again, all for a little perceived extra security.

The rules in place for the proxy server to block a site appears to be completely random.  On several occasions, I’ve Googled something I was researching, and find the golden nugget of information I needed, only to have the site blocked because it had been tagged as “a BLOG”. OH MY GOD NO, NOT A BLOG! Fortunately, I was able to get around that problem by either looking at Google’s cached version of the page, or using a mobile broadband modem to view the actual site, but either solution meant that I wasted time.

The time lost due to data loss, build problems and blocked research is significant. This happens at least twice a month, and there have been days where this has happened twice or more.  Each “outage” costs me at least a half hour, more when you consider the “in the zone” time that’s lost.

My takeaway from this is that there is less concern about getting things done than there is about blocking questionable content from the Internet.

How to retain original row numbers in an Excel spreadsheet

Monday, September 21st, 2009

Sometimes I receive spreadsheets that contain requirements or issue lists, and find that it’s hard to reference a specific row if I add or remove rows from the original document. For example, if I receive a spreadsheet with 25 requirements in it, and no unique identifier column, I’d use the row number to identify a specific requirement if I had to email a followup question. However, if I deleted one of the requirements because it was no longer applicable, the numbering would change; when you delete a row, all rows below it are moved upward. If I had referenced one of the rows under the row I’d deleted, that row number is now incorrect. The easiest way around this is to ensure that the spreadsheet has a unique ID column in it, and avoid using the row numbers. Use the following steps to add an ID column to a spreadsheet.

  1. Add two new columns to the far left side of the sheet. These will become the new columns “A” and “B”
  2. In the first row of the first column, enter the number 1.
  3. In the second row of the first column, enter the formula =A1+1; after typing the Enter key, the number 2 should appear.
  4. Copy the the second row of the first column, then select all the other rows in the first column, and paste
  5. You should now have a list of numbers in column A that match the row numbers; select them all, and then copy them.
  6. Use Paste Special to paste just the values (NOT the formulas) into the second column.
  7. Delete the first column. The new column A is now the original row number, and should match up with the ‘real’ line numbers. You can now add and delete rows and still be able to reference by the original row number.

The reason why you need to ‘Paste Special’ is because if you used formulas, those values would change when rows were added and deleted, and you’d have the original issue: unable to identify the original row number.

And now, a word about using spreadsheets to track defects or issues: Just don’t do it. Spreadsheets were made for calculating things, not to be a database. In fact, it makes a terrible database. If you need to track issues, or report bugs, use a real issue tracking system such as Bugzilla or Jira.

I would do the same for tracking requirements. While issue trackers usually do not do a good job tracking requirements, they do a better job than a spreadsheet.

The “It’ll take just a minute” myth

Monday, September 21st, 2009

clock.jpgHave you ever been at work when somebody approaches you asking for “a minute of your time”? I’m sure we all have. The problem is that the damage done by that interruption is much more than just time consumed by the interruption.

This isn’t just about the interruption taking a minute —because rarely is that true— but it’s about the time it takes for you and your brain to recover and get back into the mindset you were in prior to the interruption. A study printed in the New York Times that used Microsoft employees as a sample set showed that it took, on average, an employee 15 minutes to recover from even the most trivial of interruptions, such as an email notification.

I have known this for quite a while from my own experience, but I believe that the estimate might be a bit on the conservative side. The reason for this is that an interruption, regardless of its length or importance, destroys your concentration. The people in this study weren’t just folks off the street, but were the well trained and intelligent folks at Microsoft, so I believe the recovery time could very well be longer for most people. Additionally, I would think that the difficultly of the work in progress has an impact upon the recovery time as well, and would not be surprised that it could take as long as 30 minutes to recover from an interruption to a difficult task.

Just for the sake of argument, let’s say the person approaching you for a minute of your time really does need only a minute, and the recovery time for an interruption is 15 minutes. The total cost of that interruption to you, in terms of productivity, would be around 16 minutes, and possibly longer depending upon the difficulty of the interrupted task.

Mark McGuiness describes the reasoning behind this as a memory retention issue. Your memory is dependent upon your mind’s state; when your focus changes, as what happens when being interrupted, your mind’s state changes, and you lose a bit of the memory of the task you were working on prior to the interruption. The example he gives is one in which we’ve all participated: being interrupted in a conversation, then, post-interruption, on person asks the other “what were we talking about?”

Now, what to do about this? Banish all interruptions? Do that, and business as we know it would collapse (yes, even more than it’s already collapsed this year). Most interruptions are necessary, and the people doing the interrupting usually aren’t doing so to break other people’s concentration. There are questions to be asked and answered, but there are some interruptions that just must be told “no.” So the answer to what to do about this is something I’ll be writing about over the next couple weeks, using three different scenarios. Next will be a topic near and dear to my heart, meetings, and in specific that most evil villain the “Status Meeting”. Following that, I’ll have entries for breaks, and how to take them, and then interruptions in general.

Photo by: TW Collins

References:

High productivity

Monday, September 21st, 2009

success.pngI just finished one of the the most productive weeks I’ve had in a long, long time. Rarely did I transfer over an unfinished task from the previous day. Monday and Thursday dragged a bit, more so Thursday, but the week as a whole rocked! Unfortunately, I haven’t been able to enjoy those types of weeks very often at my current employer, which in the past has prompted me to review what it was that happened that sucked my productivity during those typical workweeks. This time, I’m going to look at what I’ve done differently this week, and see if I can apply that to the future.

So what did I do differently this week? Here’s a list:

1. Mind mapping

I first came across the term ‘mind mapping’ when I bought SmartDraw a few years ago. I looked at the templates provided, and didn’t understand how they added any value. They looked too involved and thought they would take too long to create. It wasn’t until I read about them recently in “Getting Things Done” that I finally got it: it’s nothing more than an outline of thoughts. Instead of drawing them by hand (as shown in GTD) or in SmartDraw, I created an outline using Microsoft Word (an aside to OpenOffice and Google Docs: outline views are really nice, and missing from your products). I created an outline of things that needed my attention in the short term, and then continued breaking those things down until they reached a task so small that it could not be broken down any further. As I did this to other tasks, I’d realized I’d forgotten a step in a previous task, and then added it. When I was done, I had a full list of things that were easy to do in one sitting, and had a clear map of what needed to be done for the rest of the week.

2. Conspicuous lack of meetings

My current employer is crazy with meetings. I’ve worked at much larger (in one notable case, thousands of times larger) companies that did not require as many meetings as I do now. What’s troubling is that it’s not unusual for the same meeting to occur multiple times because people left without forming a consensus on what the meeting’s resolution was. Discussing something over a cubicle wall doesn’t suffice; there needs to be a meeting. Having someone in charge make a decision doesn’t suffice; there must be a “debate”. This last week was almost meeting free, with the exception of the aforementioned Thursday. The lack of productivity on Thursday, in my mind, is directly related to the meetings, and when they took place. I’ll have more about this in a later post on the evils of meetings.

3. Lack of players

Due to vacations and two recent staff reductions, the number of people involved in the project was much smaller last week than normal; the fewer people, the less chance for things to go wrong, interruptions to occur, and meetings to go longer than needed. There were very few interruptions, and, as far as I could tell, there were no “emergencies” or unnecessary “drama” to suck productivity.

4. I still IM’d and Tweeted

I did not go full-blown isolationist in order to get things done. I kept my IM client open almost all week, and I continued to use Twitter and check my email on a normal basis (check it during natural breaks in work). The thought that IM/Twitter are productivity sinks is not necessarily true.

5. I worked normal hours

I never worked more than 9 hours in any given day (a couple of the 9 hour days were to make up for a doctor appointment early in the week); a little more than 40 hours for the week. I arrived fresh, and left before feeling overwhelmed. I can’t really distinguish this as one of the reasons for the jump in productivity, but I’ve always felt that forcing yourself to work long hours is not a productivity win, and is actually harmful in the long run. This is not a new trend; I’ve been working “normal” hours for the last few months due to health and family concerns, so while I feel it’s good for productivity in the long run, it didn’t play that big a role in the gains of the last week.

Takeaways

I’m going to continue the mind maps and the task deconstruction, and stay with the text-based outline format. Trying to create graphics or use specialized tools for that is going overboard, which is out of character, since I’m normally a very graphic-oriented person. I’ve always tried to keep a detailed task list, but breaking everything down with a mind map prior to starting seems to have helped. It also helped that the company’s goals didn’t change during the week, which allowed me to follow the map I’d created on Monday. It is not unusual to start Monday with one company vision, and have an entirely different vision by end-of-day Friday.

Meetings destroy productivity. The problem is that I’ve known that for quite some time, but have not had any success in trying to persuade management of that. My concern is that meetings and emergencies/dramas from others are well out of my control. Things will return to normal this coming week, so I’ll keep my eye on this troublemaker.

Blank your web browser to avoid distractions

Wednesday, September 16th, 2009

DistractedHave you ever had something urgent to do, fire up your web browser, then get totally sidetracked by something on your browser’s default home page? I do. Or, I should say, I did, and quite often.

For as long as I can remember, I’ve always had some sort of news portal as my start page. Back in the day, it was a Yahoo! page, and more recently it was a Google page personalized with several news and RSS feeds. It didn’t contain “fluff” like comics or a joke of the day; instead, it was local news headlines, finance stuff and a few tech RSS feeds. But often, too often, I would see a tantalizing headline or link that would divert my attention from the task at hand.

The worst type of distraction would be when I had a really good idea about how to fix a nagging defect or a way to make a page’s layout flow easier, only to forget what it was after getting five minutes deep into the latest breaking news story. Not only did I lose the five minutes I spent reading the story, I lost the incalculable amount of time it took to remember what it was I was thinking of earlier.

Then one day, just after a Firefox upgrade, it dawned on me: Get rid of the start page. After Firefox is updated, it shows a splash screen telling you about the update. Your normal start page is opened in another tab, but it was hidden by the splash. Since I wasn’t bombarded by Google’s personalized start page, I had no opportunity to lose focus. The answer was clear: don’t use Google’s personalized start page.

I then started thinking of a “proper” start page. Perhaps the home page for my site? No, a single out-of-place pixel would eventually start screaming at me to fix it, causing the same problems as the Google start page. I started thinking about posting a blank page to my site, and point to that, but that triggered something from my memory. Blank.

Both Firefox and IE have a special page called ‘about:blank’ that displays, as you might have guessed, a blank page. I set my home page to be about:blank, and now I’m greeted by a blank page that has no content whatsoever to steal my time. It doesn’t even hit a server.

The fact that about:blank doesn’t hit a server reveals a pleasant side-effect: starting the browser is now quicker. Granted, it’s not showing anything, and to get to where I want to go I have to select a bookmark, do a search or enter something in the address bar, which takes a bit more time. But it’s the page I want to see, and without distraction.

To set Firefox to open with a blank page, go to the Tools menu and select “Options…”. If it’s not already selected, click on the “Main” icon. In the dropdown labeled “When Firefox Starts”, select “Show a blank page”. Doing this allows you still set a certain page as your home page, allowing quick access by hitting Alt+Home.

The instructions are similar for IE. Select “Internet Options” from the Tools menu (or from the Control Panel), and click the ‘Use Blank’ button.


Unable to use access keys in Firefox?

Wednesday, September 16th, 2009

I recently encountered a problem with a personal web application that makes heavy use of access keys (alt + some key). During a recent cleanup that involved removing old extensions (and some that I just didn’t need anymore), the ability to invoke any action via an alt key stopped working.

The fix was to make a change to our old friend about:config. Go to about:config and filter for “ui.key”, and you’ll see something similar to the following:

The value that I needed to change was generalAccessKey, which had to be changed from the default -1, to 18, which is the character code for the alt key.

Once the value was changed, my alt key shortcuts started working again. If there is a clash between an alt key in the web application and a shortcut for a menu, the web application will win. In my case, there was a button that used alt+T to invoke an action that overrode the alt+T that normally drop down the “Tools” menu.

Topless meetings: an update

Wednesday, September 16th, 2009

As written here, I’m experimenting with laptop.jpggoing laptop-less during meetings. I believe I’m seeing the benefit to doing this, and I’m also being reminded about how distracting a laptop can be in a meeting. But first, let’s start with the benefits.

In my prior entry, I mentioned a concern about writing notes taking longer than typing them during the meeting, and then additional lost time transcribing the notes later. Fortunately, my concerns about these issues are waning. It’s not that the statements aren’t true: I can certainly type faster than I can write, and I do spend more time transcribing the notes after the meeting. But there is a huge upside to this: By typing the notes, I’m forcing myself to go over the meeting topics for a second time, expanding my comprehension of the meeting discussions (see “How I use my notebook”).

I’ve also found that there are ways to assist in speeding up notetaking by bringing pre-printed material to make notes on. Examples include an agenda, or a list of defects that need to be reviewed. Instead of writing down the agenda item, all you need to do is write the resolution and action items. A similar set of steps can be used for assigning and prioritizing defect lists.

Now that I’m laptop free, I’ve noticed issues with using a laptop and a projector and capturing notes. The “bug review” meeting is an example of the type of meeting where I notice this the most. There are two ways to run this meeting: Distribute the bugs (actually, I prefer the more direct term “defects”) on paper, and have people read of their own copy, or use a laptop connected to the issue tracking system and project the screen onto the wall, and have people read from the projected image. It seems to be much easier to use pre-printed materials and a pen or pencil than to have everyone starting at the projected image. There’s no real evidence to this, it just seems slower.

The action that makes it seem slower is when the defect is updated, it causes everyone else in the meeting to stop while the laptop user types the updated information into the system and waits for the change to be applied. This is not just a massive productivity drain, but instead it extends the time of the meeting, just the opposite of the argument for bringing laptops into the meeting.

Don’t use meeting time to figure out how software works. If you’re bringing a laptop with new software, take some time beforehand to ensure you know how to use it, otherwise, you’re just wasting the time of others in the meeting. If you must bring a laptop, ensure that all the applications, files, presentations, etc., are running and open prior to entering the meeting room. A classic example of this is the online screen-sharing applications like WebEx or GoToMeeting; in such a case, ensure you have the meeting room booked at least 15 minutes before the actual meeting starts, and then use that 15 minutes to connect and start the sharing process; don’t wait until the meeting start time to set up the session.

I’ll end with a warning regarding security and sensitive data risks for bringing laptops to meetings. When you attend a meeting, and must bring the laptop to project information onto a screen, ensure you turn off your email client, including any notification tools that you may have. Failing to do so could result in sensitive information being displayed to the entire meeting. This becomes even more serious if you’re a manager or an executive level employee.

I’ll follow up in a month or so, and see if I remain happy sans laptop…

Image: r8r

How I use my notebook

Wednesday, September 16th, 2009

I recently decided to stop bringing a laptop to meetings. That doesn’t mean I just sit idly by during meetings (that’s not to say there aren’t those meetings where I wish I could just sit idly by); I still need to capture notes that are important to me, as well as next steps of action that I need to accomplish.

Initially, I used one of those standard yellow legal pads to take notes, but I’ve never liked moleskine.jpgthe options that are faced once a page fills: To tear or fold back, that is the question. Tearing off pages invariably leads to pages getting lost, and folding leaves a near-permanent bend in the top of the paper. On top of that, both methods result in the corners of the pages becoming bent, or ‘dog-eared’, all of which is unsightly.

The option of using a spiral bound notebook was there, and in the past I’ve used the “reporter’s notebook” format, and it worked well. However, I still had the problem with the dog-eared pages after extensive use.

Then I read about Moleskine.

The hard cover prevents pages from becoming bent, and the elastic strap keeps the front and back cover together when shoved into a packed case (or laptop bag). Best of all, there’s a model that fits the reporter’s notebook format, which I find helpful because it does not take up much desk real estate, a big win at a crowded conference table.

The most important thing about a notebook is not what it looks like or how it’s constructed, but, instead, what’s inside of it. There are three categories of notes that I take during meetings:

  1. Action items (or next steps) that I need to address (I purposely do not keep track of what others need to do; that’s their responsibility)
  2. Statements or decisions that will impact my work.
  3. Followup questions or clarifications.

I usually bring two colored pens to meetings, one black and the other red. I use the red pen to write my action items down, and black for all the other types of notes. The red ink stands out from the rest of the notes so that as I capture my notes, I can quickly identify the action items and put them into my task list.

Note that I only keep track of the action items I need to address; short of dependent deliverables, I have no need to know, or track, action items belonging to others.

The “normal” notes I take, written in black ink, are limited to statements of fact that I wasn’t aware of, milestones and schedule dates, and points where a consensus was reached.

The third point above (noting questions you have) is a note taking tactic that I like to encourage others to do, and for two reasons. The first is that I find it rude to interrupt someone’s train of thought with a question. I don’t like to have it done to me, and I try very hard to keep from interrupting others. When a point of question arises, I note it down, and wait for the train of though to complete, or wait for a natural break in the conversation, and then ask the question. The other reason involves a bit of trickery on the speaker’s part. If a speaker believes that they will not be interrupted, they may embark on a long diatribe, and then assume consensus when nobody asks questions when they finish after 10 or 15 minutes of non-stop talking (this is a part of a tactic that I refer to as ‘obfuscation by information overload’). If questions are written down during the monologue, you have an opportunity to ask those questions after the speaker finally runs out of words.

After the meeting, or sometimes at the end of the day, I’ll transcribe the notes in my notebook to electronic form. I find this helps reinforce my understanding of the meeting, as I’ve written about here. I’ve used plain text files or Word documents in the past, however, now I use Evernote to capture my notes. The benefit of using Evernote is that I can access and search the notes online, as well as through a Windows client. The Windows clients also provide the ability to synchronize with a central server, so my notes are up to date regardless of which computer I’m using.

Recovering from a subversive corruption

Wednesday, September 16th, 2009

While performing a normal update from Subversion recently, I received an error stating that an error had occurred during the download, and the update stopped. This article shows how I diagnosed the problem and got svn back on track.

The error I was getting from the svn client (in this case, Tortoise SVN) was:

svn: REPORT request failed on '/repos/myproject/!svn/vcc/default'
svn: REPORT of '/repos/myproject/!svn/vcc/default': 200 OK

To ensure that this was not due to a problem in the copy of source I had, I used another PC to do a full checkout of the code. The error occurred in the same location. I then decided to look at the server logs and see if I could get any better idea of what was going wrong. Since I use svn with apache, all I needed to do was look at the apache erorr log, where I saw the following:

A failure occurred while driving the update report editor  [5000, #200002]
Can't read length line in file '/var/www/svn/myproject/db/revprops/733'

I opened the above file, and found that it was corrupted to the point of being unreadable; it appeared to be binary data.

I first tried to manually fix the properties file (revprops/733), but that had no effect other than changing the error message to something very arcane, but still reporting problems with rev 733.

svn: The REPORT request returned invalid XML in the response: XML parse error at line 79099: no element found (/repos/ASIOne_Prototype/!svn/vcc/default)

I do full backups of the subversion repositories every night using svnadmin dump. Since I wasn’t able to fix the repository manually, I had to turn to the full backup, but ran into a problem: The backup was also suffering from this same problem. Since it couldn’t retrieve rev 733 from the repository, it just stopped at revision 732.

Fortunately, I do a backup of each revision just after it’s committed. I do this with a svnadmin dump —incremental command in each repository’s pre-commit hook. I looked at the backup file for rev 733, and it appeared to be fine; it was completely readable since the corruption occurred some time after rev 733 had been committed.

I moved the original repository, and created a new myproject repository, then loaded the full backup (which went only to rev 732) using the svnadmin load utility. After the full backup had finished, I wrote a script to call svnadmin load on the per-revision backup files starting at revision 733, and going all the way to 763 (the most current rev at the time).

Once the script completed, I exported a revision I knew I had fully backed up elsewhere, created a sha1 hash file for the directory containing the source, and then compared the hashes against the backup of those files. There were no checksum mismatches or missing files.

Ensure you have backups. It’s very easy to do. To create a nightly full backup, create a script similar to the following:

mv SVN_Full.dump SVN_Full`date +%Y%m%d`.dump
svnadmin dump /var/www/svn/myproject > SVN_Full.dump

Add an entry to your crontab to run this once a day, preferably late at night or early in the morning.

Here’s what my per-revision backup script looks like:

NEW_REVISION=$1
svnadmin dump /var/www/svn/myproject -r $NEW_REVISION:$NEW_REVISION --incremental > SVN_$NEW_REVISION.dump

It takes a single parameter, the revision number of the commit just completed. Note the use of the —incremental switch. That will make svnadmin dump backup only those revisions shown in the range. Since we’re backing up only one revision, the start and end revision numbers are the same. This script is invoked in the post-commit hook with the following code:

/bin/sh /home/backup/scripts/backup_svn_rev.sh "$REV"

Topless meetings: a rebuttal

Wednesday, September 16th, 2009

While intended to be a productivity measure, the practice of barring laptops from meetings may have the opposite effect when the meeting has ended. The San Jose Mercury News and the Los Angeles Times ran stories earlier this year on the phenomenon of the “topless meeting”. While this sounds like lunch at Hooters, it’s actually the practice of barring laptops, along with PDA’s and cellphones from meetings, in an attempt to make meetings shorter and more productive.

Being that I’m at my wit’s end with endless meetings at work, I’m willing to give this a shot. My first reaction is that it’s not going to work well for me. I’m a fairly good notetaker, and I can type much faster (not to mention be much more legible) with a laptop than I can writing on a piece of paper. But I’m going to get behind it 100%. With that, here are my concerns about topless meetings:

  • Taking notes by hand takes longer and is more error-prone
  • It takes longer to transcribe the notes afterward.
  • Unable to post notes immediately after the meeting. This could result in notes being lost and not disseminated. This even applies to the practice of not taking minutes, and only capturing “next actions” on the agenda.

I agree 100% with the PDA/phone ban. I don’t care if phones are brought to the meeting, but the must be either off, or completely silent. Completely silent does not mean ‘vibrate’. I can hear most phones vibrating, and find it distracting. What’s worse is when people bring phones on vibrate mode in their pocket to a meeting, and just ignore the vibrating. Personal pleasuring aside, I find it not just annoying, but rude. If you find yourself in a position where you cannot spare 30 minutes away from your phone or PDA, then you shouldn’t be going to the meeting (and this comes from a self-confessed Crackberry addict).