Monday, June 23, 2008

Get Out of E-mail and Walk Down the Hall

I was about to write this article anyway when XKCD posted this comic which reinforces my point.  People act differently in email than they do in person.  Everyone knows this to be the case, but they often don't act like it.  Usually when someone talks about how email is different it comes in the context, as in the comic, of a flame war.  It's very easy to misunderstand someone's e-mail and assume it is more aggressive than it really is.  However, the lack of subtle emotion isn't the only downside of email.  There are times to use email and times when it isn't the right tool.  Knowing the downsides of email can allow us to better understand when not to use it.  Sometimes it is better to put down the Outlook and walk down the hall.

Some people are addicted to email.  For them, it is the only communications medium.  However, just as email has its benefits--low-friction communication medium, low interruption value, near-instant transmission time--it also has its downsides.  An impersonal nature is one of them.  While not as often recognized, so is the infinite time and space allowed.  Too much space removes the forcing factor present in conversation to boil things down to key points.  E-mail is not a good decision-making tool for this very reason.  Think about it.  How many times have you seen a discussion in email about how to implement a feature or fix a bug get bogged down in tediously long message threads with loads of new text in each message?  It can be very hard to get resolution to a contentious issue in email because email doesn't make you focus.

When there are no size and time limitations, it is easy to (attempt to) refute every point in at argument with each message.  In a person to person conversion, people can't keep a dozen arguments in their mind at once.  They are forced to focus on only the most important points.  In email, each minute point can be a breeding ground for argument.  With this point-by-point refutation, it is also easy to get lost in the minutia.  Email doesn't solve the problem that people can't keep a dozen arguments in their mind at once and so by bullet point 8, what was stated in bullet point 1 is forgotten and often contradictory arguments are raised.  In the legal profession this is called arguing in the alternative and expected.  In the rest of the world, it just makes you look dumb.  It certainly doesn't help come to a consensus answer.

Something else happens in real conversation that is missing in email.  When two people are discussing something, one person will often stop the other and drill down on something that was just said.  In email, this opportunity is lost.  It's impossible to stop someone mid-mail and ask a clarifying question.  Instead, the question is asked after the fact.  This either just adds to the complexity of the thread or distorts it because the answer would have affected the rest of the message.

While trying to hammer out a decision in email is enticing, actually getting to a decision can be hard.  Instead of just bouncing mails back and forth, stop.  Think.  Is this something that would be better handled in person where emotions are visible, communication can be interrupt-driven, and time forces a focus on the most critical points?  If so, walk down the hall or schedule a meeting.  My rule of thumb is to try email first.  When it works it is very efficient.  However, if email fails to produce results in a few messages, I pick up the phone or find the person to talk.  If its a larger group, I schedule a meeting.  Try it.  Decisions will come much faster.

For some tips on keeping meetings running smoothly, check out my post on the subject.

Saturday, June 21, 2008

Vim Tip: My .vimrc File

.vimrc is the config file for Vim.  It can be stored in the Vim directory or in your user directory.  With greater protection of the Program Files directory on Vista, I've gotten into the habit of keeping it in my user directory (c:\users\steverowe on most systems).  here are most of the non-standard options I have in my .vimrc file.  Maybe you can pick up some pointers.


"set tabs to 4 spaces.
set tabstop=4
set expandtab
set shiftwidth=4

"automatically indent
set smartindent
set cindent

"case insensitive search
set ignorecase
set smartcase

"search the whole build tree for ctags
set tags=tags;/

"open the window larger than normal (100 wide by 40 tall)
win 100 40

set nocompatible
"allow for c,w to change part of a camel-cased word
source $HOME/camelcasemotion.vim

"make it so mouse and keyboard don't exit select mode."
"this makes it so we can select with the mouse and then act on that block."
set selectmode=""

"make long-line navigation work like other windows apps
map <DOWN> gj
map <UP> gk
imap <C-UP> gki
imap <C-DOWN> gji

"from here down is the default _vimrc
set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin

set diffexpr=MyDiff()
function MyDiff()
  let opt = '-a --binary '
  if &diffopt =~ 'icase' | let opt = opt . '-i ' | endif
  if &diffopt =~ 'iwhite' | let opt = opt . '-b ' | endif
  let arg1 = v:fname_in
  if arg1 =~ ' ' | let arg1 = '"' . arg1 . '"' | endif
  let arg2 = v:fname_new
  if arg2 =~ ' ' | let arg2 = '"' . arg2 . '"' | endif
  let arg3 = v:fname_out
  if arg3 =~ ' ' | let arg3 = '"' . arg3 . '"' | endif
  let eq = ''
  if $VIMRUNTIME =~ ' '
    if &sh =~ '\<cmd'
      let cmd = '""' . $VIMRUNTIME . '\diff"'
      let eq = '"'
    else
      let cmd = substitute($VIMRUNTIME, ' ', '" ', '') . '\diff"'
    endif
  else
    let cmd = $VIMRUNTIME . '\diff'
  endif
  silent execute '!' . cmd . ' ' . opt . arg1 . ' ' . arg2 . ' > ' . arg3 . eq
endfunction

Monday, June 16, 2008

June Netcast Update

By popular demand (seriously), here is an update of the netcasts I'm listening to on a regular basis.

 

Audio:

  • This Week In Tech - Round table discussion of technology topics.  Sometimes should be known as This Week in Twitter.
  • This Week In Media - Round table discussion of issues affecting media.  Everything from DRM to Red cameras.
  • Windows Weekly - Everything Microsoft.
  • Manager Tools - Great resource for both aspiring and current managers.  Practical advice.
  • Stack Overflow - Joel Spolsky (Joel on Software) and Jeff Atwood (Coding Horror) chatting and we get to listen in.  A bit rough, but fun and informative.
  • I, Cringely - Robert X. Cringley reading his weekly column.  Not always correct, but usually entertaining.
  • FLOSS Weekly - Interviews with the names behind common open source projects.

 

Video:

 

Suggestions for additional podcasts are welcome.

Wednesday, June 11, 2008

Windows Home Server Power Pack 1 Beta Is Available

At long last, there is a preliminary fix for the corruption issue that has dogged WHS since its release.  The WHS team released the fix with its Power Pack 1 beta.  See their blog post for details and a link to download it.  In addition to the corruption fix, many other bugs are fixed and it is now possible to back up your shared folders to an external drive.  The power pack also adds supports for connecting x64 machines.

I've been using Windows Home Server for several months now and find the ease of backup unparalleled.  Just connect your machines to the server and they will be backed up each night.  No need to fiddle with anything.  I've been using early versions of the power pack and have found it very stable.  It's still a beta so treat it as such, but in my experience it's solid.  If you are running WHS, consider trying out the beta.

Saturday, June 7, 2008

Vim Tip: Better Searching

Two things I discovered about searching:


* will search forward for the word under the cursor.  No longer do I have to type /WordUnderTheCursor.


# does the same thing, but goes backwards.  It's like ?WordUnderTheCursor.


 


g* will search for any word containing the word under the cursor.  So g* on the word count will find count, GetCount, Counter, etc.


g# is the same thing in reverse.

Friday, June 6, 2008

Better Writing

The Manager Tools podcast has an interesting series on better writing.  This isn't a management-specific topic.  Rather it is something everyone can benefit from.  In a day and age where so much communication is via e-mail, having the ability to communicate your thoughts clearly and quickly is important for everyone.  One of the points the podcasts make is to keep your writing succinct and readable.  Be careful how many 3+ syllable words you use and how long your sentences are.  Put the main points up front.  Save context for an explanation after the main point or just leave it out.  Business e-mails are not a place to increase the drama by building up to the main point.  A professor once told me that in technical papers, you should be able to understand the paper by just reading the first sentence of every paragraph.  This is true of all good technical and business writing.  There are some other good tips in the podcast.  Put it on your Zune/iPod and give it a listen.

Part 1

Part 2

Wednesday, June 4, 2008

Test For Failure, Not Success

We recently went through a round of test spec reviews on my team.  Having read a good number of test specs in a short period of time, I came to a realization.  It is imperative to know the failure condition in order to write a good test case.  This is at least as important if not more important than understanding what success looks like.

Too often I saw a test case described by calling out what it would do, but not listing or even implying what the failure would look like.  If a case cannot fail, passing has no meaning.  I might see a case such as (simplified): "call API to sort 1000 pictures by date."  Great.  How is the test going to determine whether the sort took place correctly?

The problem is even more acute in stress or performance cases.  A case such as "push buttons on this UI for 3 days" isn't likely to fail.  Sure, the UI could fault, but what if it doesn't?  What sort of failure is the author intending to find?  Slow reaction time?  Resource leaks?  Drawing issues?  Without calling these out, the test case could be implemented in a manner where failure will never occur.  It won't be paying attention to the right state.  The UI could run slow and the automation not notice.  How slow is too slow anyway?  The tester would feel comfortable that she had covered the stress scenario but in reality, the test adds no new knowledge about the quality of the product. 

Another example:  "Measure the CPU usage when doing X."  This isn't a test case.  There is no failure condition.  Unless there is a threshold over which a failure is recorded, it is merely collecting data.  Data without context is of little value.

When coming up with test cases, whether writing them down in a test spec or immediately when writing or executing them, consider the failure condition.  Knowing what success looks like is insufficient.  It must also be possible to enumerate what failure looks like.  Only when testing for the failure condition and not finding it does a passing result gain value.

Tuesday, June 3, 2008

What Won't Our Kids Ever Know?

A friend of mine just posted an interesting anecdote about the difference in the world we grew up in and the one our kids are growing up in.  In his case, his son didn't know what a stereo was.  He'd never seen one.  Music in his world comes from an iPod/Zune or from a computer.  That got me thinking.  Technology is changing the world quite drastically.  What other things that were common in my childhood will my kids never know about?

They won't know telephones that have wires.  All of ours are cordless (or cellular).

They won't know a world where you only have a handful of TV channels.  We visited my grandparents' and they were perplexed by the fact that there were only 3.5 channels.

They don't understand live TV.  Everything in their world is timeshifted by Media Center.  TV schedules are an unknown to them.

They won't ever have to think about long distance phone calls.  Calling Florida is no more expensive than calling next door.

They'll never know a world where the internet is not at their fingertips at all times.  Modems?  What are those?  Encyclopedias?  What are those?

No Saturday morning cartoons.  This doesn't really fit the list, but it's true.

 

I'm sure there's a lot more that could be added to this list.  What other things will kids of this generation never experience?

Monday, June 2, 2008

Refactor To Make Immediate Change Easier

Jeremy Miller gives his reasons for refactoring.  He gives two over-arching reasons.  The first is "To remedy a deficiency in code, design, or architectural quality" and the second, "To make a forthcoming change to the code easier."  I'm very much in agreement with the second, but the first makes me nervous.  Refactoring is not an end to itself.  Changing code to make it of higher quality without an immediate purpose in mind strikes me as wasteful.  Code doesn't need to be pretty until it is being maintained.  The compiler doesn't care how ugly the code is.  The reason to make code of higher quality is because someone will may have to change that code and it will be hard to change in its low-quality state.  However, if change is not imminent, cleaning up the code now is a non-optimal decision.  Suppose the code continues working and no change is necessary in that part of the code base.  Because the compiler doesn't care and no human looks at it, the effort to make it higher quality is wasted.  Instead, it is better to wait until the change is needed to make the updates.  This would seem to be in line with the Lean principle of waiting until the last responsible moment or just in time delivery.  It is better to wait than to refactor pre-emptively.  Refactoring can become a yak-shaving exercise if one is not careful.  To be fair, Jeremy does end with this advice:  "If a structural problem in the code isn't causing any immediate harm or friction, you probably leave it alone for now."