Monday, April 28, 2003

Iceberg Sneak-Ins

This morning one of our users sent the following feature request to the Vault mailing list:

When using Vault, I frequently find myself wanting to do some operation, say a "get latest version", in the Vault client and then go to my working folder via windows explorer to do something to the folder/file/etc.  It would be really handy to have an "Open working folder" option on the pop-up menu for Vault folders which would open an explorer window to the current working directory (and save me needing to browse to it)....

(Background:  SourceGear Vault is a version control system with a user interface that is essentially identical to Visual SourceSafe.)

Within ten minutes, two more people had piled on the bandwagon by sending "me too" messages to the list.  Clearly this was a featurette that our users really wanted.

And I wanted to do it.  After all, this is a one-liner, right?  As soon as I saw the note, the corresponding line of code popped into my head:

Process.Start(strWorkingFolder);

We are very close to code freeze for our upcoming 1.1 release, so I went to chat with our Project Lead and get his opinion.  We both liked the idea, but we also both understood the most important rule about sneak-ins:

Everything looks easier than it really is.

New features are like icebergs.  Most of the effort is invisible, hiding below the water, waiting to sink your project.  The actual implementation effort is the visible part sticking above the water.

Since we can only see the part above the water, most programmers tend to forget that anything else exists.  We think only about the code, ignoring the impact of testing, bug-fixing, tech support, and documentation.  In fact, sometimes we can't even properly estimate the size of the visible piece.  In my example, all I could think of was one line. :-)

We decided to proceed with this sneak-in and I agreed to implement the whole iceberg.

• I went back to my desk and wrote the code.  When it was done, I had to laugh at myself.  Somehow my "one-line" feature required me to modify seven source files.  Everything looks easier than it really is:
  
  
  • Exactly what text should be used for this new menu item?
    
    
  • Where on the context menu should it be placed?
    
    
  • Should it appear in the main menu, or just on the context menu?
    
    
  • Should the menu item also appear on the toolbar?
    
    
  • What happens if there is no working folder set?
    
    
  • What happens if the working folder is set but it doesn't exist?
    
    
  • What does Process.Start() do when the folder has a space in the name?
  
  
• After writing the code I checked out the client spec document and updated it with the new menu command.  I learned a long time ago that every project manager can choose to spend his life in one of two ways:
  
  
  • Getting blamed because he forgot to tell everyone else how the features should work.
    
    
  • Keeping an up-to-date spec and blaming everyone else for not reading it.
  
  
• Then I wrote some GUI test procedures for the new menu command.  We keep documents which contain step-by-step instructions to verify that each feature in Vault works properly.  (We also do a lot of automated testing below the GUI level, but that doesn't really apply in this example.)
  
  
• Then I emailed the person in charge of our documentation to let her know that a new menu item had been added to the client.
  
  
• Finally, I logged in to our project tracking system and marked issue 5414 as fixed.

Bottom line, this feature really was simple, but not that simple.  Dealing with the whole iceberg took several hours.  In fact, I won't really be done with the whole iceberg until after this feature has passed QA, is being used and shows no problems.  That won't happen today, so my "one-line" feature will be hanging over my head when I go to sleep tonight.

Depending on your environment, the hidden parts of your iceberg might be easier than mine.  Many teams don't need the formality of documenting test procedures.

Alternatively, your situation might be a lot worse.  For example, my iceberg problems would have been far worse if we were doing localized builds of Vault.  If you are building multilingual software, new features don't even look easy.  In the worst case, localizing the text on my new menu item for N languages would probably have required coordination with N people, several of whom are probably at some localization shop seven timezones away.

Sneak-Ins:  Tips for Project Managers

You are the project manager.  You are responsible for the health of your project.  The spec is yours.  The schedule is yours.  It is your job to keep the programmers focused on the stuff that is important.  One of those programmers brings you a "sneak-in", a feature request which is not currently in the plan.  What do you do?

A truly conservative manager would almost always say "no".  In fact, most of the time, that's the right answer.  If you want to make your deadline, you can increase your odds dramatically by ruthlessly and callously saying "no", over and over.

But sometimes the right answer is "yes".  Good project managers are made entirely out of paranoia, but the truly extraordinary project managers have a streak of courage.  They're not satisfied to merely succeed.  They do want to ship on time, but they also want their product to be insanely great.  Sneak-ins can sometimes make a huge difference in how you and your customers feel about a product.  In one of the best product releases in my experience, the sneak-ins outnumbered the spec features. :-) 

Remember that the person requesting the sneak-in is showing initiative and concern.  They really want their app to be better.  Don't take that kind of intrinsic motivation lightly.  If the programmer understands the whole iceberg and is willing to take real responsibility, give them plenty of slack.  If you don't, they may soon be working for someone smarter than you.

Unfortunately, many sneak-in requests come from people who do not understand the whole iceberg.  Perhaps they haven't yet been burned by assuming that something is a simple as it seems.  In these cases, saying "no" is probably a good idea, especially as your first response.  You can't let half-done features destroy your schedule.

But you still need to acknowledge their good intentions.  When somebody comes into your office with an idea to make your product better, take the time to listen to their idea.  And take the time to teach them about icebergs.

Sneak-Ins:  Tips for Programmers

Three pithy rules:

1. Understand the iceberg concept.
   
   
2. Get out of your own perspective and see things through the eyes of your customer.  Do your customers really want this sneak-in, or is it just you?
   
   
3. It's easier to get forgiveness than permission. :-)