Author: Drew Kime

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.

No one cares about “average”

No one wants to be average. We just want to treat everyone else like they are. That’s why we generalize, form stereotypes. It leads to goth and emo, as kids try to be unique and different from average people … but in exactly the same way as everyone else in their preferred group. (Oops, was that cynical?)

It also leads to being pretty spectacularly wrong in your conclusions, even when you’re completely right in your premises. Take for instance what Joel Spolsky had to say about OSS development:

Development [on OSS projects] is much more likely to be geographically dispersed, which results in a radically different quality of team communication. It’s rare in the open source world to have a face to face conversation around a whiteboard drawing boxes and arrows, so the kind of design decisions which benefit from drawing boxes and arrows are usually decided poorly on such projects.

His premises are correct: development is often dispersed; design can suffer. His conclusion, that OSS projects usually just clone existing (closed source) software is not technically wrong, but is irrelevant for the same reason traditional media is wrong when they discount blogs as “real writing”: The average doesn’t matter. If the best blog — or the best OSS product — is better than the leading commercial media or closed software, it will gain market share.

As Paul Graham says:

Those in the print media who dismiss the writing online because of its low average quality are missing an important point: no one reads the average blog. In the old world of channels, it meant something to talk about average quality, because that’s what you were getting whether you liked it or not. But now you can read any writer you want. So the average quality of writing online isn’t what the print media are competing against. They’re competing against the best writing online. And, like Microsoft, they’re losing.

The “average” application on SourceForge may be derivative and just plain bad, but you don’t install averages. You install applications. I don’t use an “average browser”, I use Firefox.

This holds true for games, too. As a Slashdot poster says of open-sourcing a game:

we will see millions of variations of modifications that will be incompatible with each other and that will bring down the quality of the game. Some will be much worse than the original, probably few will add high-quality content, but some may become very good indeed.

Software, writing, games, in fact all digital media, tend toward a winner-take-all outcome. In the age of infinitely-reproducible goods, it doesn’t matter what process yields the best average outcome. What matters is what process yields the single best outcome.