Steve Rowe's Blog

10 Pitfalls of Using Scrum in Games Development

Interesting article about using scrum to manage game development.  Many of the pitfalls are true beyond games development.  The article is well balanced and has advice for how to overcome the pitfalls.  I don't agree with all of the advice, but it is thought provoking.  For example, the article makes a good point that daily standup meetings can be disruptive to the thought process.  It therefore recommends using an electronic means of tracking people that can be filled in at leisure.  I think it too quickly dismisses the collaborative effect of a standup meeting and overplays the disruptive nature.  Sure, it's a disruption, but so is lunch.  Schedule the two together.  :)  I've found that for many projects a daily meeting is unnecessary and instead meet only 2 or 3 times per week. Less disruption, same benefits.

Becoming a Manager: Losing Direct Control

When my wife was expecting our daughter, someone gave me this advice, "When you have your first child, you lose all your free time.  When you have your second, you lose all the free time you didn't realize you still had."  Becoming a manager* can be a similar experience.  When you become a lead, you lose direct control.  Instead, you have to trust what others tell you.  Very recently we had a small re-org at work and I'm transitioning from a lead** to a manager and I'm quickly finding out that I have now lost all that control I didn't realize I had.

As an individual contributor, you have complete control.  Maybe someone tells you what to do, but when it comes to executing, everything that you do gets done exactly how you want it to be done.  As a result, you know first hand the status of your part of the project.  Becoming a lead results in a loss of this control. Instead of doing the work, you have to tell others to do the work.  This results in work being done in ways you may not have intended.  You no longer have direct knowledge of the state of the project, but rather have to rely on what your team is telling you.

Becoming a manager amplifies this state of no direct control much farther.  As a lead--it turns out--you still have a lot of control.  You get to tell your team what to do and (sometimes) how to do it.  You then get to directly monitor their work.  As a result, you have direct knowledge of what they are working on and how they are attempting to accomplish it.  If something isn't to your liking, you can request a change.  As a manager of leads, there is an extra level of indirection added to the mixture.  This extra level of indirection is known as a lead and all of your instructions will be filtered through this person.  They will be applying their ideas of how things should be done before passing on instructions to the individual contributors who will then apply their own opinion before anything is actually accomplished.  This adds a lot more variance to the outcome.

As a brand new manager I don't yet have any tried and true strategies for dealing with this loss of control.  I suspect it means being a lot more careful with what you measure.  At the lead level you are interacting with the individual contributors often enough (you are having 1:1s aren't you?  and scrum standup meetings?) that you have a good pulse of the project.  You don't need to be terribly precise in what you monitor because you can measure almost everything.  As a manager, your purview is too large to measure everything.  Instead, you'll only be getting a small amount of information from each individual contributor.  Thus, picking the right things to monitor becomes a critical factor in your success or failure.

As with the lead, there is a fine line to be walked between being aloof and micromanaging (or interfering as it might be known at the manager level).  When the work is being done by people who are not direct child nodes of yours, how do you interact enough to know what is going on but not so much that you disintermediate the relationship?  These are all interesting questions I'm now facing.  As I gain more experience, I'll try to revisit this topic with some advice on what does and doesn't work.

-----

* For the purpose of this post, a manager is someone who manages other managers or leads.  This position is sometimes referred to as an M2 or manager of managers.

** A lead in this context is someone who manages individual contributors but not other managers.

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.

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

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:

• Tekzilla - User-driven technology news and how-tos.
• Cranky Geeks - Like TWiT, but on video.
• Geek Brief TV - 5-minutes a day on the latest in tech.

Suggestions for additional podcasts are welcome.

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.

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.

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

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.

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?

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."

Taking Advantage of Vim

Once you have mastered using Vim to replace Notepad.exe, it is time to starting taking advantage of what Vim has to offer.  Doing so can increase your productivity.  Below are most of the commands I use most frequently.  It is important to note that Vim has a veritable cornucopia of commands and thus supports many different usage styles.  What is presented here are just a fraction of the available commands.

Many commands in Vim have a similar format.  This format is [repetitions][command][movement].  For instance, 2dw will delete the next 2 words.

Useful commands that take this format include:

No number implies 1.  The combination cw will delete the rest of the word under the cursor and enter insert mode.  This is probably the most commonly used combination for me.

There are two more variants on these commands.  A capital letter will execute the command to the end of the line.  D will thus delete the rest of the line.  Two repeated letters will execute the command on the entire line.  Thus cc changes the whole line and 2yy yanks the next 2 lines.

Common movement commands include:

Movements can be issued without a command in front of them.  2w will move the cursor 2 words to the right.  You can maneuver all over the document using hjkl instead of the cursor keys if you like.  Personally, I use the cursor keys and only use l when I want to change some number of characters.  5cl will delete 5 characters and enter insert mode.

Some commands operate without a movement.  These include:

These commands can accept a number.  Thus 5x will delete the next 5 characters.

Other useful commands:

These commands, in addition to the search and replace command introduced in the notepad post are the ones I find myself using most frequently.  Once you become accustomed to them, editing in something without them will feel strange.  I want to hit 2cw to change the next 2 words in Word all the time.  I find the /search very useful also and miss it whenever editing in something that does not have Vim keybindings.  My repertoire is fairly limited presently.  As I discover new ways of doing things in Vim, I'll post them as Vim tips.  If there are commands you use frequently that I don't discuss above, please mention them in the comments.

We Need A Better Way To Test

Testing started simply.  Developers would run their code after they wrote it to make sure it worked.  When teams became larger and code more complex, it became apparent that developers could spend more time coding if they left much of the testing to someone else.  People could specialize on developing or testing.  Most testers in the early stages of the profession were manual testers.  They played with the user interface and made sure the right things happened.

This works fine for the first release but after several releases, it becomes very expensive.  Each release has to test not only the new features in the product but also all of the features put into every other version of the product.  What took 5 testers for version 1 takes 20 testers for version 4.  The situation just gets worse as the product ages.  The solution is test automation.  Take the work people do over and over again and let the computer do that work.  There is a limit to the utility of this, but I've spoken of that elsewhere and it doesn't need to be repeated here.  With sufficiently skilled testers, most products can be tested in an automated fashion.  Once a test is automated, the cost of running it every week or even every day becomes negligible. 

As computer programs became more complex over time, the old testing paradigm didn't scale and a new paradigm--automated testing--had to be found.  There is, I think, a new paradigm shift coming.  Most test automation today is the work of skilled artisans.  Programmers examine the interfaces of the product they are testing and craft code to exercise it in interesting and meaningful ways.  Depending on the type of code being worked on, a workforce of 1:1 testers to devs can usually keep up.  This was true at one point.  Today it is only somewhat true and tomorrow it will be even less true.  Some day, it will be false.  What has changed?  Developers are leveraging better programming models such as object-oriented code, larger code libraries, greater code re-use, and more efficient languages to get more done with less code.  Unfortunately, this merely increases the surface area for testers to have to cover.  Imagine, if you will, a circle.  When a developer is able to create 1 unit of code (r=1), the perimeter which a tester must cover is only 3.14.  When the developer uses tools to increase his work and the radius stretches to 2, the tester must now cover a perimeter of 12.56.  The area needing to be tested increases much faster than the productivity increase.  Using the same programming models as the developers will not allow test to keep up.  In the circle example, a 2x boost in tester performance would only cover 1/2 of the circle.

Is test doomed?  Is there any way to keep up or are we destined to be outpaced by development and to need larger and larger teams of test developers just to keep pace.  The solution to the problem has the same roots as the solution to manual testing problem.  That is, it is time to leverage the computer to do more work on behalf of the tester.  It will soon be too expensive to hand-craft test cases for each function call and the set of parameters it entails.  Writing code one test case at a time just doesn't scale--even with newer tools.  In the near future, it will be important to leverage the computer to write test cases by itself.  Can this be done?  Work is already beginning, but it is just in its infancy.  The tools and practices that will make this a widespread practice likely do not exist today.  Certainly not in a readily consumed form.

This coming paradigm shift makes testing a very interesting place to be working today.  On the one hand, it can be easy for testers to become overwhelmed with the amount of work asked of them.  On the other hand, the solutions to the problem of how to leverage the computer to test itself are just now being created.  Being in on the ground floor of a new paradigm means the ability to have a tremendous impact on how things will be done for years to come.

Update:  There are a lot of people responding to this post who are unfamiliar with my other writing.  Without some context, it may seem that I'm saying that test automation is the solution to all testing problems and that if we're smart we can automate all of the generation.  That's not what I'm saying.  What I advocate in this post is only a powerful tool to be used along with all of the others in our toolbox.  If you want some context for my views, check out:

• When to manually test and when to automate
• The dangers of test automation
• Too much test automation?

GVim As Notepad

When I first encountered Unix in the early 1990s, I needed a text editor.  I tried Emacs but the meta key and double control keys struck me as wrong.  I tried Vi but couldn't figure out how to type anything.  I came across Pico and for years used that as my editor.  Why?  I wasn't doing much other than modifying some shell scripts or dot files and it was easy.  All the commands I needed were listed at the bottom of the screen.  Pico is the Notepad.exe of the Unix world.  Years later I was forced to do some programming on a Linux system via an ssh connection.  Needless to say, Pico isn't really a great programming editor.  I had a friend who was really excited about Vim (Vi Improved) at the time so I gave that a try.  Emacs still didn't sound inviting. 

I began by reading tutorials on the web.  They all intended to get me up to speed on all the nifty functions in Vim very quickly.  For instance, most tutorials start by teaching that hjkl are the cursor keys.  They are, but you don't really need to know that for basic functionality.  The ones with arrows on them will work just fine for most purposes.  Options like this serve just to confuse at the beginning.  The trouble is, I can only learn so much at once.  Before I could learn how to run, I had to learn how to walk.  I needed to be comfortable doing the basics before I could grok the extra stuff.  I needed to be able to use Vim like notepad functionality before I could move on to various visual modes, regular expressions, and about 80 billions ways to get around the screen. 

This then is the tutorial I wish I had found.  It is how to use GVim as Notepad.  GVim is the graphical version of Vim.  It's the same as the shell-based version, but you get to use your mouse and there are menus.  What I am about to present doesn't show any of the power of Vim, but it will help you become comfortable enough that the myriad other tutorials on the web can be of assistance.

Modes

The first thing to understand about Vim is that it is modal.  Most editors are modeless.  Letters are entered by typing them.  Control keys do special things.  This is true all the time.  Control-S will invoke Save in notepad no matter what you are doing.  Not so in Vim.  Vim has different modes and different commands will have a different effect depending on which mode the editor is in.  It is important to keep in mind which mode Vim is in.  For now there are 2 modes you need to know about. 

First there is "normal" mode.  Vim always opens in normal mode.  This is the mode where you enter commands.  Whether you want to save a document or change the case of a letter, normal mode is where you want to be.  The confusing part is that in normal mode, you can't actually add text to your document.  If you start typing in a blank document, not much will happen.  If you start typing in a full document, all sorts of strangeness will.  In Vim's normal mode, nearly every key on the keyboard is a command.  See this graphical cheat sheet if you want to see them all.

Insert mode is probably what you are familiar with.  It's just like being in Notepad or Pico or even Word.  Insert mode works just like you expect an editor to.  The letters you type show up in the document as text.  Cursor keys or the mouse can be used to move the cursor around.  To enter insert mode, just type i.  The cursor will change from an XOR cursor to a bar cursor.  The word -- INSERT -- appears at the bottom of the screen when in insert mode.  If you are new to Vim, this is the mode you'll spend the most time in.

Esc will exit insert mode and return to normal mode.

Basic Editing

If you are using GVim, editing is simple.  Just enter insert mode and it works the ways Notepad works.  You can select text with the mouse, cut with <ctrl-c>, paste with <ctrl-v>, cut with <ctrl-x>, and delete with the del key.

To save your work, hit esc to go to normal mode.  The combination :w (write) will save the document.  Many commands in Vim are prepended with a colon ':'.  There are good reasons for this, but we won't go into them now.  Just accept that they are needed to increase the number of available commands.

Exiting Vim can be done via the menus or by issuing the :q command from normal mode.  If you want to quit without saving, :q! will accomplish that.

To load a new file, I recommend using the menus at this point in your Vim career.  If you must, :e filename will load filename.

Search & Replace

Often times you'll need to find something in your document.  To do so, enter normal mode (hit esc).  Type / following by the word you are looking for.  For example, /Steve will find the next time Steve appears in the document.  As you type, you'll notice two things.  First, the cursor immediately jumps to the first S following the cursor, then to the first St, etc.  It's doing an incremental search as you type.  In this way, you can stop when you have reached the desired location.  No need to type the whole word.  To stop, just press <enter>.  The other thing you'll notice is that all instances of the word Steve have been highlighted.  This makes it easy to see all the places in your document where the word appears.  To go to the next instance, press n while still in normal mode.

To replace some text, say the word "from" with other text, the word "to", do this in normal mode:  :%s/from/to/g.  :%s means substitute on every line of the document.  The /'s separate the parts of the command ala regular expressions.  The trailing g says to replace all instances on each line.

If you already search for the word you want to replace, the syntax can be simplified by leaving out from.  Thus :%s//to/g will replace whatever was last searched for with "to".

Conclusion

This should be enough to get you up and running in Vim.  You won't notice any advantage from Vim yet, but you will be able to edit.  Once you are comfortable with GVim as a Notepad alternative, you'll be ready to learn the parts that make Vim such a great editor.  I have a post to help with that here.

For the Non-Visual User

If you happen to be using Vim from a command-line instead of GVim, a few more commands will be necessary for basic operation.

To select text, hit <ctrl-v> to enter visual mode and use the cursor keys* to select the text you want to operate on.  If <ctrl-v> does a paste, you can use <ctrl-q> instead.

To cut or delete the selection, press x.

To copy the selection, press y (yank).

To paste a previously cut or copied selection, go to where you want to insert it and then (from normal mode) press p.

----

*This won't work in GVim.  If you know how to make it work, let me know.

Are Audiophiles Going Extinct?

This article says that they are.  More importantly, it says that people do not care as much about their music or the quality of their music-listening experience as much as they once did.  That's very interesting if true.  I wonder if this is a permanent trend or if it is temporary.  Beyond a certain point, the average person definitely does not care about the quality of their sound.  How else can we explain the explosive growth of low-bitrate MP3s?  They are moving to higher bitrates now, but when the Diamond Rio had 32 megs of RAM, people weren't listening to 192kbps tracks.  The list of high-quality audio formats built to replace the CD is long.  The list of failed products is equally long.  DVD-Audio?  SACD?  DCC?  DTS CDs?  None made more than a blip on the radar.

Of course, quality audio for music may be declining, but people are paying more attention to the audio in their home theaters now.