My response was

The estimate field is purposefully unit-less. That's because the estimate field gets used in determining how much you can get done in a week, so you could think of it in hours, minutes, days, socks, difficulty, rainbows, or whatever -- just as long as in the same list you always think of it in the same terms.

A while back, Jeff Sutherland (one of the inventors of the Scrum development process) pointed out some of the reasons why story points are better than hours. It boiled down to four reasons:

1. We are bad at estimating hours, but more consistent with points
2. Hours tell us nothing since the best developer on the team may be multiple times faster than the worst
3. It takes less time to estimate in points than hours
4. "The management metric for project delivery needs to be a unit of production [because] production is the precondition to revenue ... [and] hours are expense and should be reduced or eliminated whenever possible"

But I noticed another benefit in my personal habits. Not only does it free us of the shackles of thinking in time and the poor estimates that come as a result, it corrects itself when you make mistakes.

I recognized this when I saw myself giving higher estimates for work I didn't really want to do. Like a contractor multiplying by a pain-in-the-ass factor for her worst customer, I was consistently going to fib(x+1) in my estimates for a project I wasn't enjoying.

But it doesn't matter. My velocity on that list has a higher number than on my other list, so if anything I hurt myself by committing to more work on it weekly for any items that weren't inflated.

What do you think about estimating projects in leprechauns?

(And don't ask me how sad it makes me feel that my favorite book as a kid has only a 240px image online. I need to find my copy and scan it.)

But just like its more enlightened brethren, tech support consists of troubleshooting. In fact, it should be the first line of defense to keep your coders coding and off the phone. Who wants them to man the phones? Certainly not the programmers. Certainly not management. Tech support is a cost center, not a customer service opportunity.

That's a lie of course. It's a bajillion times more likely that you'll sell to an existing customer than someone else¹. So why do we see such poor customer service? Especially in our own industry?

Perhaps when you have a virtual monopoly over a market like most cable companies or utilities in a given locale, you can afford to have poor customer service. The cable sphere seems to be opening up, what with satellite TV and internet and now AT&T and Verizon offering television and decent-to-good internet packages. Even still, AT&T's UVerse has its own problems, I've heard, and (at least personally) I've not witnessed the kind of customer service that competition promises with regards to cable TV and internet access.

Is tech support really that bad? Maybe it's not. There are some folks that have decent starting advice. Even if it's not How To, at least Some Ways is better than no ways.

The fact is we tend to treat support like a second class citizen. It's a position we want to fill with a minimum-wage worker (or less, if we can outsource it) who has no expertise, no clue, and doesn't care to learn the product since he can get a job in the fast food industry at about the same rate. And with no stress!

It makes it worse that we don't even want to take the time to train him, since it would take away from the productive code-writing time to do so.

The person we want to treat as an ape or worse always seems expendable. We treat them so. Should they be?



I say no. Not only am I a big fan of dogfooding, I feel like Fog Creek's giving customer service people a career path nowadays matches a lot of my ANSI artist peers' experiences from back in the day. Smart people start in support, and they can move themselves up in the organization to play more "key roles."

Bill puts on a headset, sits down, and answers the phone. "Hello, this is Microsoft Product Support, William speaking. How can I help you?"

Bill talks with the customer, collects the details of the problem, searches in the product support Knowledge Base, sifts through the search results, finds the solution, and patiently walks the customer through fixing the problem.

The customer is thrilled that William was able to fix the problem so quickly, and with such a pleasant attitude. Bill wraps up the call. "And thank you for using Microsoft products."

At no point did Bill identify himself as anything other than William. The customer had no idea that the product support engineer who took the call was none other than Bill Gates.

Like Bill.

I don't think it needs to be a full-time thing, but it certainly helps if programmers are their own support team. Like Bruce Johnson who posted that linked message, I work on a small team and can vouch: it's downright embarrassing to have to support our customers. I'm glad to do it, but when it happens, more than likely I've got to take blame for the problem I'm dealing with. You know how hard I try to make sure my code works as expected before I deploy it?

"OMG I'm sorry, that's my fault, I'll fix it for you right away." Can you get better support than that?

I'm not so sure I'd have tried that hard without the customer experience pushing me.

I think I've made my first point: that customer support is customer service is important to the health of your business. While I agree that tech support in the common use of the term is useful to shield your programmers from inane requests, I also recognize the value in having programmers take those calls from time-to-time.

Given that, I do in fact have some do's and do-not's with regards to support. The list here deals mostly with how to be a good support technician for your team, as opposed to the customer. Still, the customer is central to the theory. Although it does not make an exhaustive list, here are four contributions to The General Procedures For Troubleshooting:

1. After listening to the problem description, the first thing to do is recognize whether or not you can solve the problem while the customer is on the phone, or if anyone can. If you can, then do it. If you think only someone else can do it, and work for an organization that has multiple levels of live-support, then escalate it.
   
   If you don't think solving the problem is possible without escalating it to a level of support that won't get to it immediately, thank the customer for reporting the issue, let them know the problem is being worked on, and boogie on to step 2.
   
   
2. As support, the first thing you need to do before escalating the issue is confirm there is an issue, and do it with a test account, not the user's.
   
   It's ridiculous to ask for the user's credentials. Don't do it. If someone were to ask you, "What is your username and password?" what would you think? The average user isn't going to know your query is tantamount stupidity, but if you get someone who is slightly security-conscious, you're going to lose a customer. Hopefully, he's not a representative of your whale.
   
   If anyone found out that you're in the habit of asking users for their passwords, they can easily call anyone who uses your software and get in by just asking. Further, since many people use the same password for everything or many things, that person would also have access to your customers' other sensitive information, wherever it resides.
   
   You can point the blame at your stupid customer for using the same password everywhere they go all you want. You're being just as stupid by opening the door for that type of attack. Further, you should always try to recreate and fix the problem with as little inconvenience to the user as possible. That means doing it with test accounts as opposed to asking the user for theirs, or changing their information.
   
   Keep things simple for the user. Don't jump immediately to using their time to make things easier on the support team. Doing that is lazy at best, sloppy most of the time, and could result in disaster at worst.
   
   
3. After confirming the existence of the problem, provide the steps of how to reproduce it. Give some screen shots. If it's a web app, provide links. Don't constantly send and email and ask the higher levels about it. Doing so once or twice is one thing, but doing it for every request is a time-waster. Just send the email and the next level will get to it when they can. If they don't get to it within the acceptable time-frame for your organization, send a reminder. Include the boss if you need to. But don't do that prematurely (and that's another subject altogether).
   
   
4. Don't jump to conclusions about the source of the problem. Although Abby Fichtner wasn't speaking directly to support ...
   
   
   
   ... This is the opposite of my general approach. The parallel here is code : customer :: you : dumb². I've learned (even if through a bit of self-torture) that I should always look at the code first, if for no other reason than I don't want to be foolishly blaming others when I'm to blame. In the case of support, I've always hated the term "User Error," and that's what the tweet reminds me of.
   
   By framing it as an external problem, we miss an opportunity to teach the user how to use the product, or a chance to improve the product to make sure they can't use it "incorrectly."

What are your thoughts about tech support? What can you contribute to The General Procedures For Troubleshooting?


Notes:

1) I know this statistic, it's even intuitive, but I can't seem to find it online for free. Here's some apparently made-up stats to satisfy you. Go back to what you were reading.

2) "word1 : word2 :: word3 : word4" is SAT (and elsewhere) notation for the analogy "word1 is to word2 as word3 is to word4." See freesat1prep.com for a few examples.

Some links in this post are affiliate links. This message brought to you by the Federal Trade Commission.

I came across such a situation the other day.

.

In this case I was working with static content on a website that wanted to go dynamic. It wasn't just a case of writing a spider to follow all the links and dump all the HTML into a database - there was some structure to the data, and the database would need reflect it.

In this case, there was a hierarchy of data. For simplicity's sake, let's say there were three levels to the tree: departments, sections, and products. At the top we have very few departments. In the middle, there are several sections per department. And there are many products in each section.

Each level of the hierarchy is different - so you'll need at least three spider/parser/scrapers. Within each level, most of the content is fairly uniform, but there are some special cases to consider. We can also assume each level requires roughly the same amount of effort in writing an automaton to process it's data.

It's natural to start at the top (for me, anyway -- you are free to differ), since you can use that spider to collect not only the content for each department, but the links to the section pages as well. Then you'll write the version for the sections which collect the content there and the links to the products. Finally, you get to the bulk of the data which is contained in the products. (And don't forget the special cases in each level!)

But that's the wrong way to proceed.

You ought to start at the bottom, where you get the most return on your investment first. (Or at least skip the top level.) Spidering each level to collect links to the lower levels is exceedingly easy. It's the parsing and special cases in the rest of the content that makes each level a challenge.

Since there are so few cases at the top level, you can input that data by hand quicker than you can write the automation device. It may not be fun, but it saves a few hours of you (and your customer's) time.





Carry on now, nothing to see here.

I get emails like this all the time:

"Hey Ramit, what do you think of that article I sent last week? Any suggested changes?"

My reaction? "Ugh, what is he talking about? Oh yeah, that article on savings accounts ... I have to dig that up and reply to him. Where is that? I'll search for it later. Marks email as unread"

Note: You can yell at me for not just taking the 30 seconds to find his email right then, but that's exactly the point: By not including the article in this followup email, he triggered a passive barrier of me needing to think about what he was talking about, search for it, and then decide what to reply to. The lack of the attached article is the passive barrier, and our most common response to barriers is to do nothing.

(Bold emphasis is mine).

If I can't immediately answer an email, it gets put on hold until I have time to go through and do the research that I need to do to give a proper reply. Sometimes, that means your email never gets answered because eventually I look down at the receipt date and say to myself "I guess it'd be stupid to respond now." But I digress.

In everyday software development, there are a number of barriers that can help us:

• Minimizing or closing the browser. When a compilation is expected to take up to a minute, or a test suite will run for too long, or a query takes forever, there's not much work that can be done, so I might fire up the feed reader, email, or twitter to pass the time away. The problem here is that you'll often spend far longer on your excursion than it takes for your process to complete. If you waste just 5 minutes each time, you've accomplished nothing - you're just skimming and certainly not getting anything out of it, and you could have been back working on what you were trying to accomplish. In these situations, I have my email, feed reader, and twitter minimized, and that significantly reduces the urge to open them up and start a side quest.
  
  If you wanted to get more to the active side of barriers, you might just add the line

  127.0.0.1	reddit.com

  to your hosts file. That turns a passive barrier to time waste into a downright pain.
  
  
• Having a test suite with continuous integration and code analysis tools running. At various points in a day you might be tempted to check in code that breaks the build or introduces a bug. This is especially true at the end of the day. However, if you have a test suite that runs on every commit, you're much more likely to run it to avoid the embarrassment of checking in bad code. If you've got static analysis tools that also report on potentially poor code, you're less likely to write it.
  
  
• Annoyance Driven Development. This isn't one that I know how to turn on or off, but I think it would be a great feature to have in IDEs or text editors: it gets slow when your methods or classes or files get too big. This would be a great preventative tool, if it exists. I guess it falls back to using test suites and code analysis to provide instant feedback that annoys you into doing the right thing.
  
  
• Working with others, or having others review your code. Most of us pay more attention to quality when we know others will be looking at the code we write. Imagine how much more of your code you'd be proud to show off if you just knew that someone would be looking at it later.
  
  

Just as well, there are also barriers that hinder us:

• Interruptions. This one is obvious, but so pervasive it should be mentioned. IM, telephone calls, email, coworkers stopping by to chat or ask questions - they all prevent us from working from time to time. The easy answer is to close these things, and that's what I do. They all represent passive barriers to getting work done, and you can easily turn that around to be a passive barrier against wasting time (see above). Pair programming is an effective technique that erects its own barrier to these time wasters.
  
  If you're really looking for something to help you focus, I'd have a look at The Pomodoro Technique, which divides your work into tomato time units of 25 minutes each, which really helps you focus on work. It's agile for time management. (The Pomodoro Technique PDF book is available for free.)
  
  
• Rotting Design: Rigidity, Fragility, Immobility, and Viscosity. Bob Martin discusses these in his (PDF) article on Design Principles and Design Patterns. Quoting him for the descriptions, I'll leave it to you to read for the full story:

  Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multi- week marathon of change in module after module as the engineers chase the thread of the change through the application.
  ...
  Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
  ...
  Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
  ...
  Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.

  The point is that poor software design makes an effective barrier to progress. There are only two ways I know to tear down this wall: avoid the rot, and make a conscious decision to fix it when you know there's a problem. There are plenty of ways to avoid the rot, but books are devoted to them, so I'll leave it alone except to say a lot of the agile literature will point you in the right direction.
  
  
  
  
• Unit Tests. I struggled with the idea of putting this on here or not. If you're an expert, you already know this. If you're a novice or lazy, you'll use it as an excuse to avoid unit testing. The point remains: unit testing can be a barrier to producing software, if you are exploring new spaces and having trouble determining test cases for it. I'll let the Godfather of TDD, Kent Beck, explain:

  ... I still didn't have any software. As with any speculative idea, the chances that this one will actually work out are slim, but without having anything running, the chances are zero. In six or eight hours of solid programming time, I can still make significant progress. If I'd just written some stuff and verified it by hand, I would probably have the final answer to whether my idea is actually worth money by now. Instead, all I have is a complicated test that doesn't work, a pile of frustration, eight fewer hours in my life, and the motivation to write another essay.

These are just a few examples, so I'm interested in hearing from you. What barriers have you noticed that positively affect your programming? Negatively?

Fighting it yourself requires a lot of discipline, so so as a backup in combat, I thought I'd figure out how to automate some simple actions through Quicksilver.

More specifically, this post might be entitled "Automating MediaWiki additions with Ruby and Quicksilver." I intend to do similar things for the other applications I mentioned above, but this one is specific to MediaWiki (For those who are unaware, MediaWiki runs the Wikimedia properties, including Wikipedia).

Automating this stuff turns out to be surprisingly simple. My original idea was to have a section on the Main_Page of my wiki called "Free Floaters" that would be a simple list of one-line ideas to be flushed out later. However, I ran into some trouble trying to edit it, so I ended up just giving it its own page. (Therefore, if you know how it might be accomplished, let me know in a comment!)

All you need to do is drop the following Ruby script (edited to your requirements -- I've annotated the lines you'll need to change) in ~/Library/Application Support/Quicksilver/Actions in your MacOS install.

Wiki.rb (placed in ~/Library/Application Support/Quicksilver/Actions -- be sure to chmod -x Wiki.rb)

Then restart Quicksilver. From the command line:


Now, when you open Quicksilver, type "." to enter text, tab to the action and type "wiki" (or the file name if you decide to change it), then hit enter to run it. Quicksilver passed what you typed to the script arguments, and the script sends it up to your wiki.

Any thoughts? What would you change? What else in this vein would you like to see?

Good point, @QualityFrog. I hadn't thought of it because I come in early instead, for the same reason.

I'd really like to see a "Send Sometime In The Next 24 Hours" button in Gmail, but failing that, I'll just create a place for myself to store emails in a database until an hourly scheduled job sends them via Gmail at getdate() + rand()*23.