Author: Drew Kime

The day I got a lot smarter

One sign of intelligence is the ability to learn from your mistakes. An even better sign is the ability to learn from someone else’s mistakes. Unfortunately, we don’t always have the luxury of watching someone else learn a valuable lesson, and we have to do it ourselves. But if we pay attention, sometimes we get to learn multiple lessons from one mistake. (Lucky us.)

Case in point: Dealing with a crisis. I was managing a group of web developers, and the project lead on an integration with our largest client was going on vacation. He assured me his backup was fully trained, and would be able to deal with any issues. He left on Friday, and we deployed some new code on Monday. Everything looked good.

Time passes …

On Wednesday at about 4 p.m., we got a call asking about an order. We couldn’t find it in our system. From what we could tell, the branch that placed the order wasn’t set up to use our system yet, so we shouldn’t have the order. At 5 I let the backup go home for the day while I worked on writing up what we’d found. I sent an internal email explaining what I believed had happened. I said that I would call the client and explain why we didn’t have the order, and that they should check their old system.

While double-checking the deployment plan, I discovered that the new branch actually was on our new system … as of that Monday. That’s part of what was included in the new code. That’s when I got the shiver down my spine. By that time the backup, whose house was conveniently in a patch of bad cell coverage, was gone. The lead was on vacation. “Okay,” I thought, “I’ve seen most of this code, in fact I’ve written a good bit of it. I can figure this out.”

Stop laughing. It sounded good at the time.

To make a long story short (Too late!) we hadn’t been accepting orders for three days from several branches, but had been returning confirmations for them. It was somewhere around 3 a.m. when I finally thought I knew exactly how many orders we had dropped, though I hadn’t found the actual bug in the code yet. I created a spreadsheet with the list of affected orders. At one point I used Excel’s drag-to-copy feature to fill a range of cells with the branch number for a set of orders.

Did you know Excel will automatically increment a number if you drag to copy? Yes, I know it too. At 11:30 in the morning today I know it. At 3 a.m. that night I apparently didn’t know that. So I sent it to the client with non-existent branch numbers that I didn’t double-check. “Oops” apparently doesn’t quite cover it.

The reveal

The next morning on a conference call with the client, my boss, his boss, and several other people, we were going over the spreadsheet when someone noticed the problem. To me, it seemed obvious that it was a simple cut-and-paste error on the spreadsheet. But someone — a co-worker, believe it or not — decided to ask, “Are you sure? Because I don’t see those other two branches on here either.” After dumbly admitting that I didn’t know anything about any other two branches, I ended the call so I could go figure out what was happening.

Now I had apparently demonstrated that I didn’t actually know what was wrong, that I had no idea of the scope of it, and that I was trying to cover it up. Yay me. We called in the lead (whose vacation was at home doing renovations) and started going through the code. I finally found the cause of the error, and it caused exactly the list of errors that I had sent out early that morning, except for the cut-and-paste error. The “other two branches” turned out to be from the previous night’s email, where I had specifically said those branches were not affected by the problem.

Within two hours, we had the code fixed and all the orders recovered. So everyone’s happy, right? If you think so, then you haven’t yet learned the lessons I did that day.

  1. No matter how urgently someone says they need an answer, the wrong answer won’t help.
  2. If it looks like the wrong answer, it might as well be the wrong answer. This doesn’t mean counter-intuitive answers can’t be right. It means that presentation and the ability to support your conclusion count.
  3. If you didn’t create the problem, always give the person who did the first chance to fix it.
  4. If someone knows more about a topic than you do, have them check your work.
  5. Don’t make important decisions on too little sleep.
  6. Before making a presentation to a client, review the materials with your co-workers.
  7. Don’t make important changes when key people are unavailable.

Looking at that list, I realize I already knew several of those lessons. So why did it take that incident to “learn” them? Because there’s a difference between knowing something, and believing it.

When design is not design

“How is software production like the car industry?”

Oh no, not again. Yeah, well, most people are getting it wrong. So here’s another shot at it.

There are aspects of car design that strictly deal with measurable quality: performance of the electrical system, horsepower, fuel economy, reliability. But the shape and style of the car are much more loosely coupled to hard-and-fast measurements. That facet of the design — the way it looks, the demographic it will appeal to — is not amenable to Six Sigma processes.

Granted, there are some cars that are strictly (or nearly so) utilitarian. Some people only care about efficiency and reliability. They buy Corollas by the boatload. But the FJ Cruiser is not the result of a logical, statistical analysis, with high conformance to the mean and low variation of anything.

I think what I’m trying to say is that marketing design is building the right thing, while production design is building the thing right. The auto industry is mature enough that you need both. Success in the software industry still relies more on building the right thing.

There are no IT projects … mostly

Whenever someone says something I’ve been thinking or saying for a while, it’s clear evidence of how smart they are. (Don’t laugh, you think so too.) So when Bob Lewis published the KJR Manifesto – Core Principles, he confirmed his intelligence when he wrote:

There are no IT projects. Projects are about changing and improving the business or what’s the point?

The variation that I’ve been telling people for years is that people don’t want software, they want the things they do with the software. So if you’re working on an IT project and can’t explain the benefits in terms that matter to the business, you probably shouldn’t be doing the project. Then in the middle of making this point to someone, I realized it’s not always true.

One case I thought of was a steel manufacturer that I interviewed with. While the factory was computer-controlled, the people who worked on those systems were in Engineering. The non-production computer system — email, financials, advertising, etc. — was IT. In that case, IT really was a support function, no more important to the company than telecom.

That doesn’t mean it was unimportant. They could no more survive without their back-office system than they could do without phones. But that system really had no bearing on how they ran their business. It was something that was expected to Just Workâ„¢, like the electricity or plumbing.

The thing I don’t know is if this is the exception that proves the rule, or if it’s more common than I thought to find a place where IT really isn’t a strategic partner in the business.

Maybe I’m the one missing something

Magicians make a living at misdirection, getting you to look at their right hand while they’re hiding the ball with their left hand. You’d think journalists would want to be a little more direct than that. But Neil McAllister did a whopper of a slight-of-hand recently, using more than half his column to summarize a Joel Spolsky post before jumping to a completely unrelated conclusion.

Joel’s point, and the first more-than-half of Neil’s summary, was shooting down the idea beloved of suits that programming can be reduced to a set of building blocks that can be snapped together by a non-programmer. (For a hysterically painful example of how wrong this is, and how far people will go to try to do it anyway, see The Customer-Friendly System at The Daily WTF.)

Joel covered the ground pretty well, so I was wondering where Neil was going with this. Once I got to it, I had to re-read the segue three times to see what connection I was missing:

Don’t you believe it. If, as Brooks wrote, the hard part of software development is the initial design, then no amount of radical workflows or agile development methods will get a struggling project out the door, any more than the latest GUI rapid-development toolkit will.

And neither will open source. Too often, commercial software companies decide to turn over their orphaned software to “the community” — if such a thing exists — in the naïve belief that open source will be a miracle cure to get a flagging project back on track. This is just another fallacy, as history demonstrates.

If there’s a fundamental connection between open source and “Lego programming” I don’t know about it. Maybe Neil makes the connection for us:

As Jamie Zawinski recounts, the resulting decision to rewrite [Netscape’s] rendering engine from scratch derailed the project anywhere from six to ten months.

Which, as far as I can see, has nothing to do with the fact that it was open source. In fact it seems more like what Lotus did when they delayed 1-2-3 for 16 months while they rewrote it to fit in 640k, by which time Microsoft had taken the market with Excel. Actually that’s another point that Joel made, sooner and better.

Is Neil trying to say that Lego programming assumes that code can be interchangeable, and man-month scheduling assumes that programmers are interchangeable? Maybe, and that’s even an interesting idea. But that’s not what he said, and if I flesh out the idea it won’t be in the context of a critique of someone else’s work.

Or maybe it was an opportunity to take a shot at the idea of “the community”. Although in his very next column he talks about the year ahead for the open source community, negative community reaction to the Novell/Microsoft deal, and praise from the community for Sun open-sourcing Java. Does he really dispute the existence of a community, or was it hit bait?

Okay, so where did I start? Right, with misdirection. So the formula seems to be: quote a better columnist making a point that I like, completely change the subject with the word “therefore”, summarize another author making my second point, and send it to InfoWorld. Am I ready to be a “real” pundit yet?

Blinded by experience

Don Norman knows more about design than I ever will. He even “knows” a few things that aren’t even true. That’s some powerful knowing! Specifically:

You cannot successfully introduce a non-qwerty keyboard today, or reverse the window scroll bar convention, or suddenly require double-clicking on web links.

I think Don has spent too much time lately with experienced web users, and not watching people like Lou, my father-in-law. Lou is a retired printing production manager, who trained as a graphic artist and worked for several ad agencies. He got one of the first Macs so he could use PageMaker, and used Photoshop when it was still owned by Aldus.

Lou “knows” that you have to double-click things with the mouse. He has known that for over 20 years. I’ve tried to point out that you don’t have to do that on the web. He does it anyway. His current computer runs Windows 95, so if I wanted to I could set the option to use single-click select globally. I would never set that preference on his system, though. It would drive him insane.

But Microsoft did introduce the new behavior. There is a generation that has grown up using it. Could someone do the same thing with web links? They’d have to have market penetration comparable to what Microsoft had with Windows 95, but yes, they could do it.

Here’s where it gets interesting. You could reasonably support either side of this decision: There are people who “know” that you double-click everything, and people who “know” that you single-click everything. Either one will be frustrated by a system that does the opposite. But knowing that both kinds of people exist, what should we do? In the Hippocratic tradition, first do no harm.

I can’t count the number of sites I’ve seen that instruct users to “Only click the Submit button once.” Or “Please wait for the page to load.” As soon as we start warning users what they should or shouldn’t do, two things should be apparent:

  1. Users, for some reason, think that they should do the very thing we’re telling them not to do.
  2. Some of them are going to do it despite our warnings.

If we can’t prevent users from doing the “wrong” thing with our applications, we owe it to them to at least make sure that they don’t break anything when they do.

Negotiation starts from confidence

It seems obvious when you think about it, but I don’t hear it said very often: The first step toward getting what you want is knowing what you want. You have to do more than recognize what you want, you have to be confident in it.

Here’s an example from my college days: I worked at a bar for a couple of years. On weekends, we’d have someone at the door checking ID. There were plenty of people who tried to talk their way in without any.

One night the regular doorman was late, and I covered for him. The first girl who showed up without ID smiled, batted her eyelashes and asked “pretty please?” I said something like, “Gee, I really wish I could, but rules are rules, etc.” She argued, I refused, she got mad … I’d like to chalk my behavior up to my youth and her smile, but the bottom line is I didn’t project confidence in what I wanted.

The next girl who showed up without ID (for some reason guys never tried this with me, I don’t know why) I just told her I needed ID or she couldn’t get in, sorry. She threw a quick pout, then left to find someplace else she could get into.

As I thought about this later I realized the first girl wasn’t mad because she wasn’t allowed in. She was mad because I gave the impression I might be open to negotiation but I wasn’t.

Moral of the story: Know which of your goals are negotiable and which ones aren’t. Never give the impression that one of the former might be one of the latter. Reasonable people can respect an honest difference of opinion, but will read indecisiveness as an opportunity to negotiate.

Update: I found another way of putting this, on Scott Berkun‘s site where he explains why things suck:

It’s the things that tease us, making us think they’ll satisfy us but then failing, that hurt the most.

He was pointing out that people don’t complain about things they don’t care about, but it works really well to explain what happened to me when I was working at the bar.

Here’s a crazy thought

Corel should sue people who use Photoshop without paying.

Huh?

Think about it. Graphics professionals pay for Photoshop. Lots more people do some graphics, but not enough to be worth $650. But many of those people possibly would agree that their use is worth $80.

So there are probably people using cracked copies of Photoshop who, if they didn’t have the crack, would instead have bought Paint Shop Pro.

It seems reasonable that if we’re going to report losses to “piracy” in terms of lost sales, we should be counting the potential sales that are really lost.

Writing a test approach

If this is the first time someone has asked you to produce one, it’s kind of an odd exercise.

First, recognize that you have some pretty significant prerequisites, and second that you have to consider multiple audiences. But what it all comes down to is making sure that the application does what it’s supposed to do.

The prerequisite comes from needing a good definition of “what it’s supposed to do.” I wish this were as easy as it sounds. Look at how much is written about whether/how to write specifications to see what you’re up against.

Once you have a good spec, you have two questions to answer. It’s really the same question answered for two audiences, but the answers can be pretty different: How do you ensure that it does the right thing; and how do you demonstrate to your client that it does the right thing?

Answering the first question will involve unit testing, regression testing (for upgrades), creation and execution of test scripts, etc. It’s possible a large part of the execution will actually be done by the developers.

Answering the second question — satisfying the client — requires that you talk in terms of: user interaction, use cases, end-to-end scenarios, scalability/performance/load testing, support and training needs, etc.

Imagine you are presenting a sales pitch to a client, and you need to describe how you will demonstrate the value and correctness of your application. Write a narrative proposal, eg:

Working with end users and subject matter experts (name names if possible), we will define use cases that describe the expected functionality of the application. This process should take X hours of the users’ time over the course of Y days.

These use cases will be executed and verified by someone, using volume of data extracted from source. Developers will also create automated scripts to be executed on toolname, simulating how_many concurrent users executing how_many transactions per second for how_long.

You’re not trying to actually write the test scripts yet. Start out with the higher-level description of what types of testing you expect to do, and who is responsible for writing and executing each type. Theoretically you may not know the performance figures in that second paragraph, but I find it’s better to put some numbers in front of the stakeholders and let them disagree.

Can someone give me the name of a good buggy whip maker?

No really, I want to talk to one. There should be several in every large town, just like there used to be. Because it would be immoral to deprive them of their “right” to make money in the way that they want to.

“But that’s absurd,” you say, if you’ve never heard the argument before. “You’d have to outlaw cars to protect the buggy whip manufacturing business.” Yes, and that’s exactly what the buggy whip makers tried to do: ban the car.

Copyright does the exact same thing buggy whip makers tried to do: it protects a specific business model. The “right to control copying” exists to encourage people to go into the business of creating new works.

We, as a society, benefit from having new works. We have agreed to grant creators of those works a temporary monopoly on reproducing and selling those works. If the specific method that we’re using to encourage creation actually serves to restrict creation, our method needs to change.

Everyone who thinks the RIAA is responsible for increasing the net creative output of the world, raise your hand … Everyone who thinks the MPAA is the creative force behind independent film, raise your hand …

Copyright law was a specific solution to a specific problem. It doesn’t codify some inherent human right. If the “solution” has been pushed too far in one direction, which I believe it has, it’s time to re-think the balance. Or maybe come up with some new way to encourage creation of easily-copied works.

Apples and Oranges …

… are actually pretty damn similar.

How did “like comparing apples and oranges” get to be our standard phrase for indicating that two things are so different as to resist comparison? They’re both fruit, typically about the size of a baseball, have a skin and seeds, are mostly water. There are more similarities than differences.

I assumed there was some history to this phrase, some context where it made sense. The only thing I can find is a one reference suggesting, “that the phrase appeared as apples and oysters in John Ray’s proverb collection of 1670.” Okay, that makes a bit more sense. Or at least it works better for what people mean when they say it.

But I suspect it’s more like the phrase, “You can’t judge a book by its cover.” Really? Put a Unix textbook next to a Harlequin romance and I’ll bet I can tell you a whole lot about it. That phrase originated in a time when all books were printed with blank bindings, and covers could be applied by the seller or the customer. So back then no, you really couldn’t tell a book by its cover.