This morning one of our users sent the following feature request to the Vault
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)....
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
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:
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
- 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
- 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
- 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
- Keeping an up-to-date spec and blaming everyone else for not reading
- 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
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
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
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
Sneak-Ins: Tips for
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
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
Sneak-Ins: Tips for
Three pithy rules:
- Understand the iceberg concept.
- 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
- It's easier to get forgiveness than permission. :-)