The story is told of a homeowner who notices a squeaky step in his house and tries any number of remedies before finally giving up and calling somebody in. The handyman arrives, looks at the staircase, tries the squeaky step, stands back, scratches his beard, pulls out a nail, and hammers it in. Problem solved. Time: 5 minutes.

A week later, the homeowner receives a bill for $200. Outraged, he calls the handyman: “$200 for hammering in a single nail? I can’t pay this without an itemized invoice that justifies the outrageous price.”

A few days later, an itemized invoice arrives:

Nail: $0.50
Labor: $10.00
Knowing where to put the nail: $189.50

I’ve been working on implementing the security system for our new services framework, using some relatively new Microsoft technology (the Windows Identity Foundation support in .NET 4.5). One particular component is the Java Web Token (JWT) support that’s currently in beta (“Developer Preview”).

I won’t go into the particulars of the problem here. If you’re interested, see my Stackoverflow question on the topic. It’s interesting to note, though, that I spent a total of about four days on research, trying to understand why things weren’t working as expected, and figuring out the best place to insert my own code that makes things work. The result is about two dozen lines of code.

Once again, the solution is easy once you’ve identified the real cause of the problem. I suppose it’s a good thing that I’m not being paid per line of code . . .

Not that I couldn’t have written a whole lot more code. I could have rewritten the entire JWT handler if I wanted to, in approximately the same amount of time. I would have been less confident in the result, though. I’ve seen all too many projects in which the programmers substituted typing for thought. It’s a much better thing to spend time understanding the problem and applying very localized changes.