Drew Kime

Teenagers vs. The Internet: Teens Win

2009-09-08T21:04:00.001-05:00

Today I was talking to a friend who has a teenage daughter. One night a month or so ago, she was babysitting and brought along her new phone. Which mom and dad are paying for. Since IM worked, she assumed it was free. I'm sure you see where this is going.

A one-day $900+ phone bill later, they had a talk with her about her IM-ing habits. I recalled the discussions I'd seen about a teen racking up 14k messages in a single month, and people claiming to have seen twice that.

The math is just astounding, until you realize how they're doing it: Every kid has a contact group of all their friends, and every IM goes to all of them. They've built their own follow lists, and are tweeting constantly.

In other words, teenagers have already routed around Twitter and created a distributed system to solve this use case.

Do you love your customers?

2009-08-18T15:09:00.005-05:00

Forget the money for a second. They're all broke, just divorced or downsized, moved back in with Mom and Dad. But you get up each morning looking forward to seeing them, talking to them, spending time with them.

Oh, and selling them stuff. Stuff that you know they're going to totally dig, because you totally dig it. And they love you right back for selling it to them.

Who wants to be that guy?

But you're not. "That guy" -- the sleazeball that's always pimping the latest multi-level marketing crap at parties -- doesn't really love his customers. He loves their money.

You love them for what they are. You're one of them. Except that you're good at something most of them aren't. Maybe you write music. Or you're a painter. Or you're just really good at finding great new restaurants. So you do it for them.

"Do what you love ... yadda yadda ... heard it all before."

Close, but not quite. Maybe you heard it from Seth:

Do what you love and don’t worry about the consequences.

Or you saw the Venn diagram everyone uses to tell you what to do with your life:

But maybe you also heard that you have to always put the reader first. To start from what your customers need and give it to them.

But all of this advice is missing something important.

Who are your customers?

Who do you want to spend your day with?

If you love building and painting choppers, you'll probably spend lots of time with bikers. You like grooming Pomeranians? You'll be with little old ladies and gay men.

Is that who you want to spend your day with? Every day?

Because once you've picked your niche, once you've picked who you're going to follow, that's who you're going to spend your working life with.

Pick them on purpose

Contrary to every other piece of advice I've seen on this, I'm telling you to pick your customers first. Don't start from your interests and look for a market. And definitely don't pick a market just because it's a market.

Look for people you like. People you're willing to spend time with. Lots of time. Too much time.

If you don't love spending time with these people, it'll show. You may get by for a while, finding the intersection between what they want and what you want to give.

But if you love them, you'll be willing to follow them where they want to go.

Is Google the general-purpose Napster?

2009-03-03T12:30:00.002-05:00

Napster has become an icon in the war between entertainment industry giants on one side; and fans, legal activists and computer programmers on the other. The Recording Industry Association of America (RIAA) technically "won" that battle, but they seem to be losing the ongoing war. And the Motion Picture Association of America (MPAA) is intensely interested in that outcome.

It's hard to discuss the issue though, because there are so many players involved. Because they're actually fighting for or against different things. And frequently they're using arguments that have more to do with politics than with their actual goals. For instance:

Fans talk about sharing and mix tapes, while admittedly lots of them just like free stuff.
Legal activists talk about first amendment and fourth amendment rights and fair use, but often in the larger context of resisting the corporatization of government.
Computer programmers talk about non-infringing uses of technology and the technical impossibility of implementing certain regulations, while often echoing the legal activist's resistance to corporatization.
The recording industry talks about piracy, theft, and the rights of the artists, while their real concern is control of the marketing and distribution channels.

This last point is the one I want to look at.

The official position

The RIAA has long held that any duplication of an audio recording made without the express permission of the copyright holder is, and should be, illegal. This is not technically correct.

There is, at a minimum, the fair use doctrine, which holds that works can be copied and reproduced for the purposes of comment, news reporting, teaching, scholarship, and research. So the RIAA is already stretching the truth, although they have been fairly direct in their efforts to limit the scope of fair use and restrict its application, but so far these exemptions exist.

Based on creative accounting

Have they stretched any other truths? Courtney Love and Janis Ian both argue pretty persuasively that protecting the artists is not what this is all about. Even a million-selling album barely makes the artists any money, while various industry segments take all the profit.

But repeated studies, some of which Ian mentioned, have shown that Napster users actually spent more money on new CDs. So why would the RIAA oppose it? For that you have to look at what music Napster users were buying. It was more likely to be back catalog or from a minor label. And the RIAA is designed to promote blockbuster releases from Top 40 artists.

So killing Napster was really about restricting the number of choices listeners have, and making sure the record labels own all of the remaining choices.

It's not the music, it's the information

Seen in this light, it's more clear that the RIAA is not in the music business per se. They are in the marketing and distribution business. And Napster performed both of these functions for free. And did it better than the RIAA could, because it directly reflected the preferences of the users. It's no wonder the RIAA attacked them.

So here is the iconic battle: The status quo industry controls information and access. The upstart provides information from the users, to the users, without industry input. Industry uses legal means to squash the upstart. But the genie is out of the bottle.

Who does information now?

In the generic terms I just used, you can see echoes of this battle in online search and advertising. Google, through their PageRank algorithm, represents the preferences of their users. Marketers coming from the broadcast model, where money equals attention, claim a lack of "fairness" in the system, saying that the content producers should control how their sites appear in indexes.

The battle is playing out differently this time, for a few key reasons.

First, Google got very big, very fast. By the time traditional marketers realized what was happening Google was already dominant.

Second, traditional marketing was fragmented and highly competitive. They didn't have a single trade group dictating the market the way the RIAA was controlling the bulk of the music industry.

Third, Google had a business model before they came under attack. Which means they had money for legal defense.

Fourth, and possibly most important, Google knew the fight was about information and access. They weren't distracted by arguments about artists and creators.

Which side are you on?

"You're not promoting the right thing ... Stop listening to what users say they like, I'm the one paying money, I'll tell you what people should like ... It's not fair, I've spent all this time and money on market research and your system is saying that my product still isn't popular ..."

It sounds like the same arguments the RIAA made. Companies with a vested business interest are unhappy that people don't like their product, and they're trying to shoot the messenger.

Where are you in this fight? Insisting that Google should list you because you paid more? Or analyzing what PageRank says about how people view your content, and giving users what they want?

Have you done all the marketing you can? Are you sure?

2009-01-16T17:38:00.002-05:00

Has every person in the world who could possibly benefit from your product already bought it? Wait, let's back up to an easier test. Has each one of them even heard of your product? If not, what have you done today to make sure that they hear of it?

Have you identified each potential user of your application? Not just a general description of the type of user, I mean personally identifying information. Do you have their email address? Why not? How do you plan to get it?

How many people have seen your sales pitch and not bought? What are their email addresses? How many of them would have benefitted from your product? Why didn't they buy it? How do you know?

What can you change in your sales pitch to convert more of those views into sales? How do you know?

What can you change in your product to increase the population of people who would benefit? How do you know?

This isn't black and white, where things either work or they don't. This is the squishy grey area filled with actual people, who may buy (or not buy) for reasons that they don't understand themselves. If you think getting this "right" (think about why I put that in quotes) is faster or easier than building your product, then you don't even know how much you don't know.

Naked cynicism

2009-01-14T11:56:00.004-05:00

Sales is a tricky thing. If you've got a good product that you really believe in, you can make a fortune just by convincing people that you're right.

But sometimes, it's just a "good" product. Nothing wrong with it, but not so different from lots of others on the market. So why should people by your product instead of someone else's?

Good marketing beats good product development every time. Just look at Microsoft. That's what you're competing against. Even with a better product, you have to have better marketing to win. And good marketing is measured by one thing: Is it effective?

Is there a line between strong advocacy and manipulation? Between creative license and deceit? How long do you have to be in the business before you stop caring, and just go for naked cynicism?

That’s why characterizing your prospect as a ruggedly independent thinker — immune to "herd think" — is a very powerful selling technique indeed.

If you can position your prospect as a renegade, and your product as a symbol of that individualism, it can form a powerful buying motive.

Just be sure and let your prospect know there are other people who feel the same way.

Update: Looks like someone agrees. Scion's current ad campaign tagline is "United by Individuality." Okay then.

When newspapers are gone, will you miss newsstands?

2009-01-14T09:30:00.004-05:00

Marketing guru Seth Godin asked the question today, "When newspapers are gone, what will you miss?" Before getting into the various sections and showing how the web covers each of those areas better, he offers this opinion:

Woodpulp, printing presses, typesetting machines, delivery trucks, those stands on the street and the newsstand... I think we're okay without them.

But are we?

The presses and trucks -- the machinery of creating and delivering the paper -- are transparent to most people. But the newsstand is a user interface. Any UI designer will tell you that the interface influences the type of interaction you have with the underlying system. What type of interaction do you have with a newsstand?

Newsstand in web terms

First, the newsstand serves as a "portal" to divergent news sources. It provides a rough snapshot of what the different publishers think is worth reading about today, all in one place. No matter what your interest, you can go to the newsstand and know that it's represented there.

Then there are the cases where someone discovers an interest while at the newsstand. The user who knows what she is there for, but sees the same screaming headline in 144 pt type on three different papers and decides she wants to see what's happened in the world. Or the user who wants to read something, but doesn't know what until he browses. This second type of user is very common in airports.

The newsstand also serves as a feed reader, always showing the most recent issue of periodicals and dailies, with older issues sometimes available behind the counter. Just as there are people who don't know or care about RSS readers, there are people who have been reading magazines for years who don't track when the new issues will be out. They just check the stand every day or so until they see something new they want to read.

Don't make me think

Both of these functions, the portal and feed reader analogues, are zero maintenance for the users. At most they might ask the proprietor to start carrying a new title. But the mechanics of delivery, storage, display, are all handled for them. With no subscription, no ongoing cost, and the incremental cost entirely under the user's control.

So Seth is right, we probably won't miss the newspapers. But will we miss the newsstands?

Being Useful Is Better Than Being Right

2008-09-15T13:59:00.005-05:00

Being right isn't nearly as important as most IT people think. Understanding why that's true is one of the fastest ways to build trust and respect with the non-IT management in your company.

Let's try an example where it's better to be useful than to be right.

Suppose you find out there is a structural problem with your building. It is severe enough that the building could collapse at any moment.

Being Right

You look up the emergency notification policy in the employee handbook. There's a number to call. You call it and explain the details of what you've discovered. They start asking questions about evidence, as you get frustrated that they're not responding fast enough to this emergency, and why don't they get it?

Being Useful

You pull the fire alarm and everyone leaves the building.

Business Prefers Useful

Executives like to get things done. They got where they are by being good at getting what they want. The respect and respond to that trait in others.

So if you want to be recognized as someone who can get things done, you need to actually get some things done. If excruciating detail is what it takes to convince someone they should listen to you, then use detail. If a convenient metaphor will make your point more strongly, then use one. Of course it will gloss over important details, that's why we use metaphors. They simplify reality in a (hopefully) useful way.

Find a good balance betwee rightness and usefulness, and you will take control of your career like you never imagined you could.

You can't unplug a book

2008-08-27T11:13:00.001-05:00

The first printing presses were used to print bibles. And porn. That's not a value judgement, just an observation.

The internet was first used to distribute scientific and academic papers. And porn. It seems man hasn't changed much in the last few centuries.

The printing press and the internet share some other features. Like the impact they had on society: education, communication, freedom. Plenty of people have written about the similarities. Some have written about the differences. But I haven't seen much conversation about one important difference: Books can't be turned off.

Why this matters is that writing is something that can be entirely learned by each person who uses it. There is no risk of being unable to use the technology.

I’ll grant that large-scale printing presses are far beyond the reach of individuals, and even whole cultures. But the base concept of printing is so simple that it could be easily duplicated, and scaled up by anyone with basic mechanical aptitude.

Computation is a whole different animal. The utility of "pervasive computing" is explicitly the pervasiveness. The smart chip in my credit card is useless without a reader. Or a computerized register to attach the reader to. Or an internet connection between the register and the VISA system. Or … or … or …

Look at any major urban blackout. Commerce comes to a complete standstill within minutes. You can literally turn the technology off, and society grinds to a halt.

If you smash a printing press, everyone who already had a book still has it. If you burn all the books, people still know how to write.

But disable the networks that allow us to engage in commerce, and suddenly the grocery store shelves go empty. And we don’t have local farms any more to fall back on.

I’m not suggesting that we’re likely to face a protracted breakdown in the current system. But the impact of such a breakdown is certainly on a new scale.

Emboldened by Ignorance

2008-08-01T08:28:00.004-05:00

Fans and followers of Tim Ferris are already familiar with his concept of the low information diet and selective ignorance. The basic idea is that there is so much information in the world, and so much news coverage, that you could spend your life keeping up-to-date and never have time to do anything for yourself. By cutting down on the amount of news you follow, you regain time for yourself.

But there's another benefit of selective ignorance that might be even more powerful. If you look hard enough, you can find a good (sounding) reason to not try anything:

Don't record a blues album, no one listens to the blues.
Don't travel abroad, terrorists have threatened the airlines again.
Don't self-publish your book, they never sell.

If Brunonia Barry had known what she was doing was impossible, she never would have gotten a seven-figure book deal when she finished. According to her husband Gary Ward, "We were emboldened by our ignorance. We knew just enough to get going, but not enough to stop us."

He encouraged Brunonia to self-publish her debut novel "Lace Reader". They brought un-bound prints of the book to local book stores and clubs and solicited feedback.

That just isn't how books are published. Authors submit manuscripts to publishers and wait for an offer. Then the publishers tell the authors when, where and how the book will be marketed. But Ward and Barry didn't know that.

Had they known how the publishing business works and, more importantly, had they "known" that what they were doing wouldn't work, there's a good chance no one would have ever heard of "Lace Reader". Instead, reprint rights have been sold in 20 countries and Barry is in discussion for a movie deal.

Bold doesn't mean stupid

The danger of ignoring your critics is that sometimes they're right. When Simon Cowell tells someone that they can't sing, there's a good chance he's right. He's an expert.

That's not the person you want to ignore. The ones to tune out are the naysayers who tell you, "That can't work. No one does it that way."

Every great thing was once the new thing that no one did. Until someone ignored the critics and did it anyway.

So listen to critics. Pay attention when someone has done exactly what you're trying and has valid feedback. But if all they have to say is, "No one does it that way," maybe that means you'll have the field all to yourself.

How To Tell When You're Being Lied To

2008-06-09T16:11:00.003-05:00

If you've ever watched more than 30 seconds of a late-night infomercial for a real estate selling "system" you've seen some version of the exact same pitch. "Do what I tell you on the tapes and you'll be rich." But the only people making money are the ones selling the tapes. No one ever gets rich actually following the advice on the tapes.

It doesn't matter what the tapes are about: real estate, home cleaning products, debt consolidation. They're all a scam, because the real money is in selling the system, not in using the system.

The new wrinkle in this is that the scammers have gone "meta". The system they're selling now is the infomercial. Instead of claiming their system will tell you how to sell real estate, they claim their system will tell you how to make your own infomercial. Which can be about real estate, or it can be about ... well, making more infomercials. And making them on the web. See, it's different!

You would think that eventually someone has to get something of value out of the whole arrangement. With the real estate scam someone allegedly gets a house out of it. But with the new racket the only thing that ever comes out of it is a "business" of selling more ads.

If you're too young to know about it, they have a name for this arrangement: Ponzi Scheme. The only people who make money are the people who know that's what they're doing.

So here's how to tell when you're being lied to. If what you're doing is a Ponzi Scheme, are you the one doing it on purpose? If not, then you're being lied to.

Do You Demand Flowers From Your Staff?

2008-06-09T13:41:00.005-05:00

What are you supposed to buy for your wife for Valentine's Day? Quick, first thing that pops into your mind ...

Right: flowers. A dozen long-stemmed red roses. Because decades of consistent marketing has worked its magic on you. You could debate that it should be a box of chocolates, or jewelry, and I'd say that's because those two industries have been advertising just as hard.

But have you noticed the hidden assumption? That you're "supposed to" buy something at all. No matter how aggressively the flower, candy and jewelry industries market against each other, none of them will ever contradict this fundamental belief: That extravagant purchases are the approved way to demonstrate commitment.

Most modern American corporations expect you to demonstrate your commitment, too. But instead of flowers the symbol of your commitment is time. Time above and beyond the forty hours you're supposed to work. Time eating at your desk instead of going out to lunch. Time on call via the Blackberry they gave you.

Doing good, steady work is better for the company. But late-night marathons of work get noticed. If you plan well and execute, you don't need late nights, but then there's never a clear moment for the boss to look at and say, "That moment really showed commitment."

In a perfect world, the boss would take the extra effort to recognize good, steady performance. And that's exactly what it takes: extra effort. Which is why it happens so rarely. Even if you're doing things on time, it seems that sometimes you have to put in the late night to get noticed. Because this isn't a perfect world.

But you may be in a position to make the world a little better. If you are the boss, make the extra effort. Publicly recognize employees who reach their goals during normal working hours. Make it clear that late nights are a symptom of poor planning. Demand extra work because it needs to be done, not just to show commitment.

It may be less exciting, and less obvious, but in the long run it's much more productive.

How To Stop Turning Down Work

2008-06-09T12:50:00.006-05:00

It's your sixth birthday and your grandfather has just handed you a ridiculously heavy package the size of a shoebox. You open it up to see that yes, it is a shoebox. A shoebox full of pennies.

"I've been dropping all my pennies in there each night since you were born," he says. "I planned to give it to you when it's full, and it's getting close. There's probably more than $200 in there. All you have to do is count them out into stacks of fifty and roll them in those little paper sleeves." This was before the automatic coin counters appeared in grocery stores.

Your six-year-old mind reels at this windfall. You count and wrap until your hands are cramped. You beg you mother to take you to the bank to turn the pennies into "real money," then straight to the toy store to get Frogger for your Atari. (Any similarities to the author's life are purely coincidental.)

Flash forward to today. Someone offers you a box of pennies. All you have to do is count them by hand. You might still take it, but it's not going to be such an obvious choice. How long will it take? What could I be doing instead?

Thinking small

For the mid-career freelancer, this is the calculation that dooms you to punching a clock. You could build that website for the local restaurant, but they want you to keep it up-to-date with their specials. You're not interested in doing maintenance, and they can't afford to keep paying your development rate. So you don't take the work.

You just turned down a lucrative contract because you're thinking like an employee. No, you don't have a boss, but you still think that any hour you're not working is an hour you're not getting paid. To break this mindset, you need to start delegating. You need people working for you.

You're making it as a freelancer because you solve people's problems. When someone wants a site and ongoing support, they have two problems. You can solve the first by building the site, and the second by finding a qualified support person. There are plenty of online resources for finding contract technical workers. Don't make your client go to these sites and try to evaluate people, do it for them.

Thinking big

Instead of selling a Content Management System that will allow a small business owner to update his own site, offer a one-stop service, where your employees will keep the site updated for a monthly fee. Do this enough times and your "passive income" could exceed your new development work.

But even if you don't take a cut of the support fees, having the capability means you can bid on a whole new type of contract: the large kind.

How many Danny DeVitos does the world need?

2008-06-02T08:34:00.005-05:00

Seth Godin is absolutely brilliant at questioning the assumptions and "conventional wisdom" that we all rely on when promoting our products or services. He doesn't offer step-by-step recipes "Guaranteed to triple your sales!" In fact he rarely talks about specific numbers at all.

And if his recent post Thinking about Danny Devito is representative, then it's a good thing he doesn't. Because he completely missed the point that "a few" is a whole different thing than "one."

If you haven't read it -- and you really should, it's only 152 words -- the point is that there are a lot more people competing for the George Clooney-type roles than there are competing for the Danny DeVito-type roles. Seth phrases this pseudo-mathematically:

(number of people resembling George Clooney)/(jobs for people resembling George Clooney) is a much bigger number than the ratio available to Danny. For the math challenged: Because everyone in Hollywood is trying to be George, there are a lot more opportunities for the few Dannys willing to show up.

Since his breakout role in Taxi in the early 80s, DeVito has 76 acting credits. During that time he's also had: 33 producing credits, 13 directing, 6 soundtracks, and 76 appearances as himself. It's fair to say he's prolific. And as long as he's able to maintain his pace, he will remain the first choice for anyone who wants someone resembling Danny DeVito.

Think about that phrase, "resembling Danny DeVito." Then consider this chestnut about the career of a movie star:

Who's Brad Pitt?
Get me Brad Pitt.
Get me a Brad Pitt type.
Get me a younger Brad Pitt.
Who's Brad Pitt?

Now try to come up with a list of actors who you would describe as "a Danny DeVito type." Or "a younger Danny DeVito." I'll wait ...

Yeah, I can't come up with any, either. So it seems that, for now, the important formula is (jobs Danny is able to take)/(jobs for people resembling Danny). And for now that ratio seems to be "one." And "one" is really not at all close to "a few."

How to negotiate a better contracting rate

2008-04-23T13:31:00.006-05:00

In any transaction, the person with more information and more experience usually comes out ahead. That's why the typical consumer negotiating with a full-time salesman is at a huge disadvantage. A car dealer, for example, might negotiate several sales every week, while you only do it every two to three years.

So people making big decisions -- new car, new house, new job -- do as much research as they can, trying to level the playing field just a little bit. And lots of the information they come up with is flat out wrong.

One of the most damaging pieces of advice to follow when looking for a job is to rely on a headhunter's self-interest to get you the best rate. The idea – which seems quite reasonable on the surface – is that the headhunter's commission is a percentage of your salary. Obviously they want this number to be as high as possible. It's easy to believe that their self-interest lines up with yours.

The first flaw with this idea is that the headhunter doesn't get anything if someone else gets the job. If there are multiple qualified applicants, you are on the wrong side of a bidding war. The contractor doesn't want to price you out of the running, so the incentive is to lowball your rate.

The second flaw is that every day the headhunter spends searching for your perfect job is day they don't spend finding a job for the dozen other people they're working with. They make more money by placing more people than they do by placing fewer people at higher rates. 30% of $70k x 3 is more than 30% of $80k x 2. Their incentive favors the quick hit, not protecting your interests.

So what do you do about it?

Stop thinking of the headhunter as your own personal agent.
They're doing a job for you, but they are more interested in getting you something than in getting you the best thing.

Know what you'll accept before taking the interview.
Have a bottom line that you won't go below. Based on what you hear in the interview, you may decide to demand even more to accept the conditions. But your lower limit should never be negotiable.

Ask what the range is for the position up front.
There's no point in wasting time on a position that you'll never take.

Never give up something for nothing.
If they want you to travel and you don't want to do it, ask for extra vacation in return. If they want you to be on call, ask for comp time. Never give up one of your demands without getting a concession in return.

Get it in writing.
You can't deposit a promise in the bank, or buy groceries with verbal assurances.

So are all headhunters ready to sell you out at a moment's notice? Of course not, even if it's just to preserve their reputation. But if you want to avoid being disappointed, you should never forget that your best interest only sometimes matches up with the headhunter's interests.

How To Triple Your Output By Cutting Your Output In Half

2008-04-01T10:58:00.015-05:00

The fastest typist I've ever seen was a guy I used to work with. When he started going it sounded like a machine gun. Our standard line when people asked the rest of us about him was, "Yeah, he types over 150 words per minute ... and about 40 of them are spelled right."

Even after you ran his stuff through a spell checker, you'd have to proof-read very carefully to catch the places where "there" and "their" were mixed up. Where single letters showed up at random because the spell checker skips one-letter "words". Where he left out words or just plain didn't make any sense.

It usually took longer to fix his stuff that it would have taken to do it yourself from scratch. So why did we put up with it? Well, he was the boss. Keen.

But like anything else in life, you can at least learn something from the situation. What I learned from him was that it doesn't matter how much you produce if no one wants it. Or put another way: Anything you do for someone else that isn't up to their standards doesn't count.

For an example of an entire industry that's working as hard as possible to ignore this simple truth, compare television today to what it looked like in the 1950s.

The golden age

Back then there were three networks. How many prime-time shows did they collectively produce per week? Counting 8-11 p.m. Monday through Friday, that's three 1-hour slots x five days x three networks = 45 hours of programming. Lets say a third of those hours were broken up into half-hour shows, so a total of 60 shows per week.

Let's assume that to have a consistently great show you needed six extremely talented writers and actors. (Yes, there's a lot more to it. This is just an example.) The fewer good people you have, the less often your show will be good. To fill 60 shows, you might have the following mix:

Show quality	Talented staff per show	# of shows	Total talented staff
Consistently great	6	1	6
Excellent	5	2	10
Very good	4	2	8
Good	3	18	54
Sometimes good	2	35	70
Generally poor	1	2	2
Total		60	150

Obviously every network would like their shows to be better. But for whatever reasons there are only 150 people with the level of talent needed to produce a weekly show.

Double the output

Fast forward a couple of decades. Now there are six networks. The talent requirements to produce a good show are the same, but there aren't suddenly twice as many talented people available to do the work. The chart above might now look a little something like this:

Show quality	Talented staff per show	# of shows	Total talented staff
Consistently great	6	1	6
Excellent	5	1	5
Very good	4	1	4
Good	3	6	18
Sometimes good	2	21	42
Generally poor	1	75	75
Unwatchable - bad	0	15	0
Total		120	150

Notice how many shows had to drop into the lower categories to make this work. The contrast is really obvious when you look at the two outcomes side-by-side.

With twice as many total shows, there are fewer shows that are even sometimes good. By doubling the total output, there are fewer than half as many shows that are ever acceptable to the audience And there are only a third as many shows that are usually good.

These numbers are obviously a gross oversimplification, but they illustrate a point: By increasing the output without increasing a limited, but required resource the overall quality declines faster than the total output increases.

500 channels and nothing's on

Now fast-forward to today. There are literally hundreds of networks trying to fill 24 hours every day. Granted, with the amount of money flowing in the industry there may be more people willing to work there. But if my assumption is at all close to reality, then we would expect to see shows that clearly don't have anyone talented working on them. We might even see shows where they simply send a camera crew out to film people without a script. We might call this a "reality" show.

So you're not in the TV business. How does this apply to you? Everywhere in the example above, replace "talented staff" with "attention". How much undivided attention do you have each day? How many ways are you dividing it? By trying to do more things, are you doing fewer things well?

VB3 is just fine for running your business

2008-03-13T09:32:00.001-05:00

"... all those cheapskate companies running said VB3 app for 15 years will have nowhere to go, because their shitty app won't run on it and they won't pay to have it redone with modern tools."

You've got some typos in there. Let me fix those for ya:

"...all those fiscally responsible companies running said VB3 app for 15 years will have nowhere to go, because their well-written app that has performed its intended function without fail won't run on it and they don't need to pay to have it redone with modern tools."

Analogy time:

I've got a 25-year-old fridge in my kitchen. Even if a new one saves me 50% of the electricity used it would take about 13 years to pay back the cost of buying the new one. And don't talk to me about the environmental cost of that wasted power, since the impact of manufacturing the new one dwarfs the power used over its lifetime.

If you think you're saving money, or helping the environment, by scrapping working appliances in favor of newer, more-efficient ones, you've fallen for someone's marketing plan. Just like all the people who want to re-write functioning apps in the cool new language du jour.

It's time to cheat on your publisher

2008-02-06T16:19:00.000-05:00

With the current generation of high-speed digital printers, print-on-demand [POD] publishers are making aspiring authors feel wanted like they've never been wanted before. It seems like everywhere you look there's another slick come-on ... free ISBN numbers, your own storefront, listings on Amazon.com.

For someone getting propositioned for the first time, it's easy to fall into a deep relationship with whoever offers the nicest package. The smart ones make it really easy to say "yes". It's just so simple and comfortable, let them take care of everything for you.

I bet you can see this coming

Then something goes wrong and you realize how dependent you've become. All those links on your blog pointing to the order page. All the people you've told where to find you. The PayPal account you set up to take the payments.

It sure was easier to get into this relationship that it seems to be to get out. You tell yourself the problem -- whatever it is -- isn't really that bad, come to think of it. At least it's not bad enough to be worth the pain of finding someone new.

You don't think that time is going to come? Well, you may be right. Through some combination of luck, work and compatibility you may have found the perfect partner for the rest of your publishing life. But do you really want to jump into things that deeply without seeing what else the world has to offer you?

So what's the alternative?

The great thing about all these options is that you can try lots of them without guilt. You realize, if think about it, that they're hooking up with every other writer on the planet just as fast as they can. You're nothing special to them, so why should they be anything special to you?

So play the field. Sign up everywhere you can find that doesn't have setup fees. Upload, test, experiment, enjoy the thrill of it all. And see who actually gives you what you really want: sales.

Are you wasting your time being productive?

2008-02-01T14:45:00.000-05:00

Most people think that wasting time means you're not doing anything. Maybe they include not doing anything productive. But can you be doing something productive and still wasting time?

To answer the question, let's go back several years to a time before optical mice were common. I was working the helpdesk at a law firm. I got a call from an attorney that his cursor was skipping around the screen erratically. It was pretty obvious from his description that there was gunk in his mouse.

I had just started explaining to him how to remove the mouse ball to clean it out, when my supervisor tapped me on the shoulder and told me to bring him up a new mouse. I said, "But it only takes five minutes to clean it out."

She replied, "He bills $600 an hour. Bring him a new mouse."

I didn't know the term at the time, but she had just taught me a lesson in opportunity cost. If whatever you're doing is less valuable than what you could be working on instead, you are wasting time.

How corporations spin a risk into a benefit

2008-02-01T14:19:00.001-05:00

James Maguire, managing editor of Datamation, wrote in Indian IT Firms: Is the Future Theirs?

"In the past, companies used to award IT outsourcing contracts that were longer, 7-10 years. They would hire one firm to do it, and that firm would have subcontractors," Ford-Taggart says. Now, big clients split up major projects and request bids on individual components. "Then they'll say, "Look, we can have this portion done in India for 30% less.'"

This might cause more managerial headaches for the client company, but in fact it's less risk: clients have fewer eggs in a basket with any one IT firm, so if a projects goes bad or creates cost overruns, the entire project won't take such a big hit.

Emphasis added.

I hate this corporate executive definition of "risk". And before you think I don't get it, I understand what they mean but I think they're wrong.

When I talk about reducing risk, I mean that I'm making problems less likely to occur. What the execs mean when they take this position is that they're diversifying the accountability. They want to be able to report that while 20% of the project is at risk, the other 80% is on track.

Well sure, the other 80% can't be used without the 20% that's missing. But the focus here should be that we've got 80% of the project on time and on budget!

If you admit up front that your process is increasing management headaches, you should realize you're increasing the likelihood of problems. You may be mitigating the potential impact, but that's not a given.

Any mitigation strategy that seeks to minimize the impact of a failure, and does so by increasing the liklihood of failure, is probably a bad idea.

How using people in your ads increases sales

2008-01-31T16:53:00.002-05:00

We've all seen the light beer commercials with young, impossibly attractive people guzzling a product that, by all rights, should be making them fat and unhealthy. The obvious question is, "Do they think we're really that stupid? That we think if we drink their beer we'll become supermodels?"

Good question. But it gets the real thinking backwards.

When you show people using the product, you're helping the prospect visualize themselves using it. Make it seem familiar and safe, instead of new and unknown.

But since you can't put each viewer into their own personalized version of the ad (yet), you have to use a stand-in. If you show someone that the viewer would like to be, it increases their desire to want to recreate that image.

So you don't want the prospect thinking, "If I use that product, I will become like that cool, attractive person in the ad." You want them thinking, "Because I am cool and attractive, I can see myself using that product."

It's the same thinking that leads to cliques and fads:

I'm not cool because I wear Air Jordans. I wear Jordans because I'm cool.
I'm not tough because I play rugby. I play rugby because I'm tough.
I'm not a redneck because I drive a truck. I drive a truck because I'm a redneck.

You don't want your prospect to think your product will make them more attractive. You want to help them confirm what they already believe about themselves.

Why no one wants software: a case study

2008-01-31T11:59:00.003-05:00

No one wants software.

Really, no one.

What they want is documents ... pictures ... loan applications ... insurance claims ... Software is just another tool they can use to maybe produce more of the things they really want, better or cheaper.

What this means to legions of unhappy, cynical programmers is that no one cares about the quality of the code. Nope. They don't. And odds are, they shouldn't.

Here's a little story to illustrate why. (By the way, this is the kind of thing you'll see in an MBA course. If you don't already do this kind of thinking, you should stop telling yourself there's no value in getting an MBA.)

The pitch

I'm in charge at an insurance company. I have a manual, paper-based process that requires 100 people working full time to process all the claims.

Someone comes in and offers to build me a system to automate much of the process. He projects the new system could reduce headcount by half. It will take six months for a team of four people to build.

If you're a programmer, and you think this probably sounds like a winner, try looking at the real numbers.

The direct cost

100 claims processors working at $8/hour. $1.6M per year in salaries. (Let's leave benefits out of it. The insurance company probably does.)

Four people on the project:

architect/dev lead, $100/hour
junior dev, $60/hour
DBA, $80/hour
analyst/UI designer, $75/hour

Total $325/hour, or about $325k for six months' work.

Still sounds like a winner, right? $325k for an $800k/year savings!

Except the savings doesn't start for six months. So my first year savings are at best $400k. Damn, now it's barely breaking even in the first year. That's OK though, it'll start paying off nicely in year two.

The hidden costs

Oh wait, then I need to include training costs for the new system. Let's figure four weeks of training before processors are back to their current efficiency. Maybe a short-term 20% bump in headcount through a temp agency to maintain current throughput during the conversion and training. Add the agency cut and you're paying $15/hour for the temps. 20 temps x $15/hour x 40 hours x 4 weeks = $48k one-time cost. Now my first-year cost is up to $373k.

And don't forget to add the cost of hiring a trainer. Say two weeks to create the training materials plus the four weeks of on-site training. Since this is a high-skill, short-term gig (possibly with travel) I'll be paying probably $150/hour or more. $36k for the trainer.

So if everything goes perfectly, I'll be paying $409k in the first year. And actually, I don't get even the $400k savings. I can't start cutting headcount until efficiency actully doubles. Generously assume that will be three months after the training finishes. Now I've got three months of gradually declining headcount, and only two months of full headcount reduction. Maybe $200k in reduced salary.

Of course you need to add a percentage for profit for the development company. Let's go with 30%. So ...

The balance sheet

Software	$325k + 30% = $422.5k
Trainer	$36k
Training (temps)	$48k
Total Y1 cost	$506.5k
Projected Y1 savings	$200k
Shortfall	$306.5k
Y2 savings	$64k/month

The project breaks even near the end of the fifth month of year 2. And that's if NOTHING GOES WRONG! The code works on time, it does exactly what it's supposed to, I don't lose all my senior processors as they see the layoffs starting, etc. etc. etc.

The other pitch

Then a lone consultant comes in and offers to build me a little Access database app. A simple data-entry form to replace the paper version, a printable claim form, and a couple quick management reports. Two months' work, and I'll see a 10% headcount reduction. The consultant will do the training, which will only take a week because the new app will duplicate their current workflow.

Software	$200/hour x 8 weeks = $64k
Training	$200/hour x 1 week = $8k
Total Y1 cost	$72k
Savings	$12.8k/month (starting in the fourth month)

The project breaks even six months after the project is done, so early in the ninth month of Y1. Since the scope was much less ambitious, the risk is also lower.

The obvious choice

Which sales pitch do you think I will go with? Does that mean I don't respect "proper" software development practices? And, the bottom line: should I spend more money on the "better" solution? And why?

The difference between innovation and sloppiness

2008-01-30T11:01:00.000-05:00

I took a couple of art classes in college. In Life Drawing we were supposed to look at the arrangement or person in front of us and put it on paper. In pencil, then charcoal, then ink … watercolor … oil … etc.

I was always good at photorealism. I might not have been fast, but I had some pencil drawings that could have passed (at a distance) for black-and-white photos.

There was another student, an art major who fancied himself an "artiste". His work spanned the range from abstract to really abstract. He looked down on my mere technical facility.

But my grades were as good as his, sometimes better. It seems when he talked about his rejection of formal rules, it really meant he wasn't able to do realism. He didn't have the command of the tools, the mere technical facility. So everything he did owed as much to chance as to intent.

He may have been right, that I didn't have the creativity to do modern art. I'll admit that I appreciate paintings that simply look good, without high-flying pretension or socio-political overtones. I guess I'll never have a SOHO gallery showing. C'est la vie.

But with all his fervor, and whatever glorious visions he had in his head, he couldn't reliably get them onto the paper. He couldn't create something specific, on purpose.

[Cue un-subtle segue ... ]

But what does this have to do with the business world? Scott Berkun wrote recently about how constraints can help creative thinking. When a large corporation does "blue sky" thinking, they can wander aimlessly and never produce. Constraints set a direction.

But I think there's another problem with "blue sky" thinking that goes beyond a lack of direction. It's summed up by Voltaire's famous maxim:

The perfect is the enemy of the good.

When a company tries to "blue sky" a problem, they are implicitly seeking perfection: With no limits, what would be possible?

But there are always limits. They may be self-imposed, inconsequential, misunderstood, overblown, or in any number of other ways not real limits. And it helps to know the difference.

When you start out by asking people what they would do if there were no constraints, don't be surprised when they come back with a solution that can't possibly work. And then convince themselves that theirs is the only possible solution. By then, you've already lost.

Hate the game if you want, don't pretend it isn't being played

2008-01-14T16:26:00.000-05:00

When I was in college I worked at a bar that had a pool room. I played a lot when it was slow and after hours. I got pretty good on those tables. Only "pretty good" and only on those tables ... I knew where the dead spots were in the rails.

If I put anything on the game, it was usually who bought the next round. Sometimes we couldn't drink as fast as we played, and we'd go for a dollar a game. We were all friends, and it was just to make the game more interesting.

But every so often someone would come in who none of us recognized. You could usually tell really fast who was better than just a casual player. Sometimes they'd see if they could get a game for $5. I'd always take them up on it. And I always won the first game.

Then they'd ask for a rematch ... let them win their money back. I'd take that game, too. Sometimes I'd win, sometimes not. But I was breaking even so I didn't care. It was usually after the second game that they'd look at their watch and realize they had somewhere they needed to be. But they had time for one more game.

How about one last round for $50?

No.

How about $30?

No.

Come on, give me a chance to win it back!

No, you're a better pool player than I am. But you suck at reading people. You thought I didn't know you were throwing the first two games.

That's when they'd get pissed. It wasn't fair that I took their money even though they could beat me without trying hard. I was just a punk-ass bitch that couldn't carry their stick.

Yup. But I had their money, and they were leaving.

If I wanted to, I could have spent the equivalent of a full-time job becoming a professional level pool player. I would have run into diminishing returns as I was going up against ever stronger competition. It would have dominated my life, and the only way to make a steady living would be constant travel.

Plus there'd be no retirement plan. Your earnings stop the moment you stop playing. The skills don't translate to anything else worthwhile.

So I stayed in school and learned to be a programmer, which doesn't suffer from any of those negatives. </sarcasm>

Hmm, that came out a lot longer (and a lot faster) than I expected. It all started from one idea, though: You don't win by being better, you win by playing better. And you start by knowing what game you're playing.

When you're in an interview, you're playing the "get the job" game. Once you have the job you're in the "impress the decision-makers" game. If you go the uISV route you're in the "sell the most product" game.

Being better at coding is one of the plays in each of those playbooks. But it's not the one they keep score with.

Is your resume hot or not?

2008-01-14T16:20:00.001-05:00

Getting a job is like getting a date.

There may or may not be rules to it.
It may or may not be fair.
They may be so desperate it doesn't matter what you say. But do you want to hook up with someone who's desperate?
Or maybe it doesn't matter what you say because they've decided the answer is "no" before you opened your mouth.
The more in-demand you are, the more choosy you can afford to be. But if you want to get this job -- or this date -- then you're probably going to have to say what they want to hear. Good luck figuring out what that is.

Please don't believe anything in this post

2007-12-19T08:44:00.000-05:00

In Yet Another Internet Forum Discussion About Offshoring (I hereby claim authorship of the acronym YAIFDAO) someone wrote:

A lot of decisions should NOT be left to developers to make. imho, the time to think out of the box is gone by the time it is TIME TO CODE. It's not time to think about alternatives to what to do.

That is absolutely right. You never want developers talking to end users. They might suggest some other plan than what was painstakingly shepherded through four levels of approvals.

And let's just squash the notion right now that sometimes there are trade offs to consider. Just because the analyst's solution will take three weeks of coding effort and a new application server, while the programmer knows of a reusable component that will take one hour and no increased hardware, is no reason to institute the Change Control Process.

Alternatives should always be considered in isolation from the impact they cause. Implementation issues should never be allowed to intrude into the world of business decisions.

Next thing you know someone's going to suggest that maybe mere programmers could have a meaningful contribution to make to the business process. What rubbish.

How to Kill a Project by Accident

2007-12-13T10:23:00.000-05:00

In my last post I talked about perverse incentives in project management. Something I mentioned in passing was what happens when you don't have positive incentives: the cases where there is simply no incentive to do the right thing. I realized there's actually another way to get this wrong by trying too hard to get it right.

Let's say you have just finished a project, gone into production, and it blew up. Data corruption, security problems, too slow, everything that can go wrong with a product. First you do an emergency project to fix it, then you do the after-action review to see what went wrong.

What you find is that you didn't have good test coverage. There were whole modules that were never reviewed before going into production. It's painfully obvious that there was a complete breakdown in the QA process.

Fixing yesterday's problem

You're not going to make that mistake again. You write up policies for demonstrating test coverage. You create reports to track test execution and results. You re-write employee performance expectations to align with the new methodology. (If you've read my stuff before, you should hear the alarm bells start ringing when you see the "m word".)

Your next project is going exactly according to plan. Test coverage is at 90% overall, with 100% of high priority use cases covered. You're on schedule to execute all test cases before acceptance testing starts. Defects are identified and corrected.

Then the users get it. They hate it. It doesn't do anything the way they wanted it to. Not only that, it doesn't even do what they asked for. How could you be so far off?

You don't get what you don't measure

Look back at what incentives you created. You reward doing the methodology, following the checklist. Test coverage is great, but it's not the goal of the project. The goal is to provide something of value to the users ... or at least it should be. Did you include a line in the new process that explicitly says, "Check with the users that it's doing what they need"?

So how do you create the right incentives? Just flip the emphasis. Instead of saying an employee's performance evaluation is 80% following the methodology and 20% client satisfaction, turn the numbers around. Your users don't care that you followed "best practices." They care that the product does what they need. Where is that measured in your methodology?

How to Fail by Succeeding

2007-12-06T12:32:00.000-05:00

Dave Christiansen over at Information Technology Dark Side is talking about perverse incentives in project management, which he defines as:

Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.

One class of these perverse incentives comes from the methodology police. These departments exist to turn all processes into checklists. If only you would follow the checklist, everything will work. But more importantly, if you follow the checklist you can’t be blamed if you fail.

How’s that for perverse?

A great example is that there is rarely any incentive to not spend money. Before you decide I’m out of touch with reality, notice I didn’t say “save money.” I said “not spend money.” Here’s the difference.

IT by the numbers

Let’s say you do internal IT for a company that produces widgets. Someone from Operations says that they need a new application to track defects. If you follow the checklist, you:

engage a business analyst, who
documents the business requirements, including
calculating the Quantifiable Business Objective, then
writes a specification, which is
inspected for completeness and format, then
passed on to an architect, who
determines if there is an off-the-shelf solution, or if it needs custom development.

At this point you’re probably several weeks and tens of thousands of dollars into the Analysis Phase of your Software Development Lifecycle. Whose job is it to step in and point out that all Ops needs is a spreadsheet with an input form and some formulas to spit out a weekly report?

Let’s put some numbers to this thing.

Assume the new reporting system will identify production problems. With this new information, Operations can save $100,000 per month. A standard ROI calculation says the project should cost no more than $2.4-million, so that it will pay for itself within two years.

Take 25% of that for hardware costs, and 25% for first-year licensing, you’ve got $1.2-million for labor costs. If people are billed out at $100/hour – and contractors can easily go three to four times that for niche industries – that’s 300 man-weeks of labor. Get ten people on the project – a project manager, two business analysts, four programmers, two testers, one sysadmin – and that’s about seven months.

If everything goes exactly to plan, seven months after the initial request you’re $2.4-million in the hole and you start saving $100,000 per month in reduced production costs. Everyone gets their bonus.

And 31 months after the initial request, assuming nothing has changed, you break even on the investment. Assuming the new system had $0 support costs.

But what if …

Way back at the first step, you gave a programmer a week to come up with a spreadsheet. Maybe the reports aren’t as good as what the large project would have produced. You only enable $50,000 per month in savings. That week to produce it costs you $4,000 in labor, and $0 in hardware and licensing.

You are only able to show half the operational savings, so you don’t get a bonus. You don’t get to put “brought multi-million dollar project in on time and on budget” on your resume.

And 31 months after the initial request, the spreadsheet has enabled over $1.5-million in operational savings.

How to Finish IT Projects Faster with Less Documentation

2007-05-14T12:27:00.000-05:00

If you’re responsible for running an IT project you want things to be done on time and within budget. So how do you set your schedule and budget? Hopefully you define what you want to accomplish, and then ask the developers how long it’s going to take. If you’re putting out a request for proposal (RFP) you’ll have several different answers to that question. Typically the highest consideration in the selection is the total proposed cost. But really, the total time is a better choice.

Why that's true is based not on ideas about processes, but on ideas about people.

Consultants live and die by billable hours. In the short term, they don't have any incentive to finish their current project any faster. But in the long term, finishing faster should lead to more work as clients come to respect their ability to meet a deadline. If project managers and clients learn to value that behavior, that is.

How it Could Be

Let's look at a production support issue for an example. Production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn't work on Tuesday. Make it work just like Monday again.

For something with six-figure impact per hour of downtime – and if you think that’s an artificially-high number you've never worked with credit card processing – you don't want a programmer with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch and demands $1k per hour with a four-hour minimum.

Once you've got Bob and his hand-picked team of support people, you get out of their way and let them work. Status reports might be no more than, "We've found the problem … We've identified the solution … We’re ready to test the fix … It’s live."

How it Is

But when it comes to new development, companies play it "safe" and look for the best qualifications on paper. They hire based on keyword matching and offer rates based on industry standards for a given skill set. They require specific processes and deliverables (pet peeve: when did "deliverable" become a noun?) and status reporting becomes a significant percentage of the total budget.

Why the Difference?

There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The public answer business sponsors tell themselves to justify the exception to "official methodology" is that the experts have worked the methodology for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.

But I suspect the larger reason is that experts get the work done so much faster there just isn't enough time for documentation to build up.

The best athletes make things look easy that most people could not even do. A high jumper might clear six feet without even trying hard. Most people would never come close even with months to try.

The best IT people do the same thing. They complete projects in weeks that other people could never do. As "safe" projects drag on specifications are refined, status reports are produced, contracts are negotiated, updates are requested and provided. Meanwhile another project team has just released to production – so it must have been a small project.

The hard part for the client is to recognize the difference between a project that went smoothly because it was easy, and one that went smoothly because the team made it look easy. But here’s the secret. You don’t really need to recognize the difference.

How to Do Better

The reason you hired someone else to do the work is because you couldn't do it yourself. Which means you can’t accurately judge which projects are actually hard, and which ones just look hard. So don’t judge the project, judge the people.

The people who seem to always be working on small, simple projects – after all, they always go quickly with no major problems – are better at execution. They will be better no matter what the project is.

A Tale of Two Techies

2007-03-29T09:06:00.000-05:00

You've just finished learning MS SQL 4.2 and VB 5 in school. You get a job with a company that has just upgraded to those languages. You get to learn the ins and outs of the languages along with the rest of your co-workers.

Two years later you want to upgrade from your entry-level salary. You know that big raises only come from job hopping, and you see that most of the job ads are for VB6, so you start studying it on your own. You find some cool new things you think would help in your current job and start pushing people to upgrade.

Your tech lead, Bob -- who has been with the company for seven years -- says the current applications are stable and it's not worth the cost to upgrade. The boss listens to Bob instead of you. You say bad things about Bob on an internet forum.

You find a new contract gig working with VB6, and making almost as much as Bob does. Boy, Bob sure is dumb. If he had any balls he'd have jumped already. You start racking up frequent-flyer miles chasing the next gig. Bob evaluates and recommends a new third-party tool that uses VB6. He gets a VB6 class for his whole staff included in the project cost.

Five years later, you're a .NET hired gun and you know which airports have the best frequent-flyer clubs. You've got a fat bank account and all the best buzzwords on your resume.

Bob is still with the same company, but now he's the IT Director. He's not making as much as you, but he's vested and his 401 is looking pretty good. He hasn't touched any code in a couple of years, but has a few long-term employees working for him whose opinions he trusts. He also hasn't answered an after-hours page for a few years.

You meet Bob on a street corner one day and talk about old times, catch up on what's been happening. Suddenly a car jumps the curb and puts you both in the hospital. Oops.

You were smart enough to get good medical insurance, but your income stops since you're not billing hours any more. Bob goes on medical leave. His wife takes his two children out of junior high and comes in to visit. Your pregnant wife comes in to visit. (You spent your twenties traveling, so are just starting your family.)

Three months later, Bob goes back to work part-time while you sit at home, surfing the net, searching for a gig that will give you the flexibility you need to work around your physical therapy.

By the end of the year, your savings are gone. Microsoft has released the Next Big Thing after .NET, and you don't have any work experience with it on your resume. You're applying for maintenance gigs on "legacy" apps -- two-year-old .NET apps written by guys straight out of school, who just left for their first not-entry-level jobs. Maybe in another year or two you'll be able to climb back onto the leading edge.

Bob just accepted an internal transfer to run the division he's been supporting for the last decade. He recommends as his replacement the long-term employee who filled in for him during his absence. The last division head held the job for 15 years until his retirement. Bob could do the same, and retire with a decent pension when he's 60.

Principle: Everyone should hit the ground running

2007-02-20T13:27:00.000-05:00

Total size of the codebase doesn't matter. Everything a new programmer touches is either shared by other parts of the system or it's not. If it's shared, the new guy probably shouldn't be touching it anyway. If it's not shared, it should be small and self-contained enough to learn it quickly.

Now if you've got a guy in his first month who wants to re-write your DB access class, then you've got a whole different problem than just getting him up to speed. And if he's right about it needing to be re-written, the problem isn't with the new guy.

How to avoid analysis paralysis in the interview

2007-02-20T13:18:00.000-05:00

Prepping for a job interview is a little like a politician prepping for a debate. There are certain questions you can count on hearing, and you prepare canned responses to them. In the job interview these would be things like, "Why did you leave your last job?" and "Where do you see yourself in five years?"

Then there are the technical screening questions. They'll focus on your experience and knowledge. Typically you'll get some basic stuff to begin with, just to see if you really did all those things you put on your resume.

Then you start getting to the interesting questions. The ones that don't have a clear "right" answer. Or do they? Does the interviewer have something specific in mind? Will I blow it by not coming up with the right answer?

Take these two technical questions as an example:

1) When or why would you consider using an RDBMS (like MySQL etc) as opposed to a desktop database (sqlite etc)?

2) When creating a function how many parameters would you allow that function to handle?

Programmers tend to enter the field, and stay in it, because they're good at finding right answers. Computers are (mostly) deterministic. The upside for the programmer is that they know with certainty when they've solved a problem. The downside is that they know with frustrating certainty when they haven't. They can't just dress up "because I said so" in reasonable-sounding logic and turn it in. Their program has to actually work.

But the questions above don't have right answers. They aren't intended to see if someone knows how to implement a given solution. They're intended to see if someone knows how to ask the right questions to choose the right solution.

Anyone can look up a linked list implementation, or a quicksort. Most interviewers are more interested in identifying the guy who can figure out which one to use.

For the parameters question above, I'd want somebody to state a basic rule of thumb -- probably something from 3-10 "feels" like a reasonable starting point. But they should also explain their reasoning, which might be along the lines that too many parameters is likely to indicate too much going on in one function. Then possibly present an exceptional case where a high parameter count would be preferred.

Maybe there would be some discussion around passing an array of name/value pairs instead of multiple individual parameters, or named parameters, default values, etc. Or pro/con on passing all the values for an object in the new() declaration, vs. a basic instantiation and then multiple set() calls.

These specifics are not the "one right answer". They're examples of the kind of answer I'd hope to hear. If I asked you the question and you couldn't either float some ideas or ask some reasonable questions, I'd take it as a sign of lack of experience. Interviews are not a multiple-choice test, they're essay format. If the interviewer or the candidate acts like it's multiple-choice, they're wrong.

Trying hard to not get it

If you're interviewing people for entry-level jobs, maybe you do just need to know that the candidate can implement a particular pattern. Once you get past entry level, you'll want to see that the candidate can identify which pattern they should implement. Best is to find a candidate who knows why to choose a particular pattern. Which means they know other patterns and why not to choose one of them instead.

You can make it through a class in school only learning the one technique that you're going to be tested on. That's why entry level people aren't trusted to make choices, just do what they're told. Once you get out of the classroom, you have the freedom to re-invent everything, making the same mistakes everyone has made before you. The more ways you've seen to solve a given problem, the more choices you have. I'm not interested in finding someone who's always going to choose the same solution as me. I want someone who knows the general principles and how to prioritize competing goals.

But some programmers will get nervous, and others downright hostile, if you ask a question without a clear right answer. As far as they're concerned, it's a "bad question" that you shouldn't even ask. Apparently any question where the answer starts with "It depends" is a trick question, and even asking it is an insult.

How you should answer

Remember those courses you took where the instructor would tell you to show your work? Even if the answer was wrong, you could get partial credit for having the right approach. When interviewing it's all about showing the work. The "right" answer is almost incidental.

But sometimes there is a right answer. Doesn't that matter? Absolutely. And knowing whether you're dealing with one of those questions or not is an important skill.

If my goal is to evaluate whether someone knows how to clarify an incomplete requirement, I don't start by telling him, "Now I'm going to give you an incomplete requirement to see if you know to clarify it." I ask a question as though there is a right answer and see what they say.

So maybe you read all of this and think that now you know what I'm looking for. That doesn't help you with someone else who may have a different plan. The good news is that it doesn't matter, as long as you answer truthfully.

If the interviewer is looking for a specific answer and you give multiple alternatives, you may be giving a better answer than what he expected. Or maybe he'll disagree with your reasoning and decide that you are wrong. Do you want to work for someone who will shoot down your ideas?

Or the question was supposed to be open-ended but you give a single definitive answer. A good interviewer will prompt you to explain, maybe even asking about specific alternatives. Did you have a good reason to discount those answers? Explain it. Did you not think about that? Admit it. Maybe you're really not a good fit for this position.

Sure, you need a paycheck. But unless you are desperate you also need a good fit. If you and the person you'll be working for don't see things the same way, you won't get that fit. So instead of trying to overanalyze what the interviewer "really meant", just answer as honestly and completely as you think you can. If you, the interviewer and the position are a match, all that's left is to talk about the money.

Get to the point

2007-02-19T15:42:00.002-05:00

Dave Christiansen over at Information Technology Dark Side has a good graphic representing what he calls the FSOP Cycle (Flying by the Seat of Your Pants). The basic idea is that when smart people do good things, someone will try to reproduce their success by doing the same thing that worked the first time.

The problem with trying to do this is that every time someone tries to document a "successful process", they always leave off the first step: get smart people working on the project.

Dave outlines several reasons why capital-P Process will never solve some problems. Joel Spolsky described this same issue in his Hitting the High Notes article when he wrote, "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years."

So if Process can't solve your problem, what will? According to Dave, it's simple:

Put a smart PERSON in the driver's seat, and let them find the way from where you are to where you want to be. It's the only way to get there, because process will never get you there on its own.

I'll assume that when Dave says "smart" he really means "someone good at solving the current problem". I could have the world's smartest accountant and I wouldn't want him to remove my appendix. Okay, I don't want anyone to remove my appendix. But if I needed it done, I'd probably go find a doctor to do it. So what Dave is saying is that you'd rather have someone who's good at solving your current type of problem, than have Joe Random Guy trying to follow some checklist.

This isn't a complete answer, though. Some songs don't have any high notes.

In the middle of describing why you should choose the most powerful programming language, Paul Graham writes:

But plenty of projects are not demanding at all. Most programming probably consists of writing little glue programs, and for little glue programs you can use any language that you're already familiar with and that has good libraries for whatever you need to do.

Trevor Blackwell suggests that while that may be changing, it was still true at least until recently:

Before the rise of the Web, I think only a very small minority of software contained complex algorithms: sorting is about as complex as it got.

If it's true that most programming doesn't require the most powerful language, it seems fair to say most programming doesn't require the best programmers, either.

You might notice at this point (as I just did) that Dave wasn't talking about programming, or at least not only programming. The same principle seems to hold, though: Average people can do the most common things with the most common tools. Exceptional circumstances require exceptional tools and/or exceptional people. If only there were a way to predict when there will be exceptions …

The other problem

But let's say we're looking at genuinely exceptional people who have done great work. Should we ask them how they did it? After all, they're the experts.

Well, not really. They're only experts on what they did, not why it worked. They might have simply guessed right. Even if they didn't think they were guessing.

Need another example of false authority? Have you ever heard someone describe a car accident, and attribute their survival to not wearing a seatbelt?

First, they don't know that. They believe it. They obviously didn't do a controlled experiment where the only difference was the seatbelt. Second, even if they happen to be right in this case, statistics show that it’s much more common for the seatbelt to save you than harm you.

So if you want to design a repeatable process for creating software, you can't do it by asking people who are good at creating software.

The other other problem

One change I'd make in Dave's FSOP diagram is in the circle labeled "Process Becomes Painful". It's not that the Process changes. Really what's happening is that the project runs into some problem that isn't addressed by the current Process.

Every practice you can name was originally designed to solve a specific problem. On very large projects, there's the potential to encounter lots of problems, so extensive Process can simultaneously prevent many of those problems from appearing.

But attempting to prevent every conceivable problem actually causes the problem of too much time spent on the Process instead of the project.

That's where Agile comes in. It solves the problem of too much process. Do you currently suffer from too much process? Then you could incorporate some ideas from Agile.

But make a distinction between using ideas to deal with specific problems, and adopting a whole big-M "Methodology". Once you adopt a Methodology designed to solve the problem of too much Process, you face the danger of having too little Process.

Your expert programmers may be the best in the world at the problem you hired them for. But now you want them to do something different. And you have no way to recognize that they're not making progress, because you've eliminated all the governance that came with the heavyweight Methodology.

So what's the point, anyway?

Process is not something you can measure on a linear scale, having "more process" or "less process". Always adding practices -- even "best" practices -- to your current Process is simply trying to solve all possible problems, whether you're currently having them or not.

For each practice you have to consider what it was designed to solve, what was the point of it to begin with? Then don't treat these practices as a checklist that must be completed every time, but follow the principles behind them.

There's a line in the movie "Dogma" that I think describes this really well. Just substitute "process" for "idea" and "Methodology" for "belief":

You can change an idea. Changing a belief is trickier. Life should be malleable and progressive; working from idea to idea permits that. Beliefs anchor you to certain points and limit growth; new ideas can't generate. Life becomes stagnant.

What conclusion would you like me to reach?

2007-02-19T11:06:00.000-05:00

Why is it that the rest of the world has functioned fine on estimating projects of many sizes and scopes, then sticking to them; while IT screams "OH WE can't do that!"?

I'll admit a large reason is because lots of people in IT are really bad at estimating. But part of the reason we've managed to stay so bad at estimating, and the main reason all estimates seem to be so far off, is that the business side wants the estimates to be low.

The common complaint is that IT projects are "always over time and over budget". Since the IT budget (for software) is almost entirely salary, time and budget are synonymous. When you set the budget, you’ve just set the time.

But most IT projects -- and nearly every one I've worked on -- have a budget set before the detailed design is ever done. Or at least the clients have an idea in mind what they'd like it to cost. So without realizing they’re doing so, the clients set the time estimate sometimes before they’ve ever talked to the developers.

I had to help out some less-experienced people who were being asked for estimates. I told them the trick is to figure out a diplomatic way to ask, "What number would you like me to say?"

The funny thing is that this is not just being cynical, either. There's real value to it. If you're thinking four months and the client says three days, there's a good chance you don't have the same idea in mind for what you plan to do.

For instance, they ask you to write a search engine "like Google" to put on your intranet. You're thinking a couple of months. They're thinking end of the week.

It turns out they want you to buy a Google search appliance and integrate it into the intranet. To the client, "write" "create" "implement" "install" and all those other words we use that mean different things ... all mean the same thing: work that the IT guys do.

So if you want to get the work -- or if you’re an employee and have no choice in the matter -- see what number they have in mind already and tell them what they can have in that length of time. If you don't promise to deliver something in the given time frame, they'll go find someone who will. Not that they'll deliver in that time, but they'll promise to deliver in that time.

Compare this to construction. The client may get five quotes for pouring concrete. If four of the bids are close to $50k, but one of them is $20k, the client will likely assume the low bid is unrealistic and choose among the remaining contractors.

But if a programmer or independent software vendor says some work will cost $50k, the client can find someone who will promise to deliver for $20k. The sponsor will either accept the lower bid, or use it to negotiate the first vendor down to $25k. When it ends up costing $50k, that project goes in the books as "over time and over budget".

What would it look like if construction bids were awarded the same way? If for instance the client were required by law to select the lowest bid? Then contractors would low-ball every bid to get the contract. You’d end up with construction that always ran over time and over budget. You would need an endless supply of money to stay in business. You would need to be … the government.

Installing software is not worth my time

2007-02-15T13:57:00.000-05:00

My PC is managed according to corporate standards. I can't install anything without an administrator signing on and authorizing it. I asked if I could install the software to link to my cell phone and load my contacts into it. Otherwise I'd be spending a couple of hours over the next week manually entering them all in via the keypad.

The day after I put the ticket in, someone called up and asked where the software was. I told him I had it on a CD. The local support guy came up the next morning, saw that it was an OEM disk and not some random thing I'd burned, and logged in as administrator so I could install it.

Sure, it was two days before I got what I needed, but it wasn't a compelling gotta-have-it-today issue.

Everything else on here is available as a network install, and is set up in my profile. When I get a new PC -- I'm due to be refreshed in the next month or so -- I'll go to a single application, check the boxes for everything I need, and go to lunch. When I come back, everything will be installed.

Every application that I install myself I'd have to reinstall when I get a new PC. How many hours would that take? Multiply that by the number of users in my office, which just relocated earlier this year. Most of us didn't take the hardware from the old location, we just came to blank systems at our new desks and kicked off the install process.

If I'm paying for it, it is not worth my time to install software. If my alternatives are to load all my apps on a new PC I've just bought, or to work a billable hour and pay someone else to do the installs, I'll pay the Geek Squad to click OK and reboot 14 times. Why should I expect the company I work for, who owns the PC I'm working on, to make a different decision?

The program is not the product

2007-02-09T13:20:00.000-05:00

Managers want programs to be like the output of a factory. Install the right robots and tooling, start the process, and good software comes out the end.

WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG!!!!!! (Can you tell I disagree?)

Nearly everyone who makes the factory analogy misses a very fundamental point: the program is not the product. For one thing, unless you work for a software company selling shrink-wrapped software products you aren't ever selling the program. Conventional wisdom says most programmers actually work for internal IT, so it's safe to say most programs are never sold.

Businesses don't want programs, they want credit reports ... and loan contracts ... and title searches ... and purchase orders ... and claim forms ...

So what is the right analogy? The program is the assembly line! So measuring bugs in the program is wrong. Even comparing compiling to manufacturing -- which is better than comparing programming to manufacturing -- is wrong. What you should be looking at is the output produced by the program.

Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally shouldn't care what the process looks like, nor what tools are used, so long as it consistently produces the same output. This is not to say the process and tools don't matter. A bad process may be prone to unexpected failure. Tools may be harder to maintain or have a shorter service life. You may be locked into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that the program is not the product, the program is the assembly line.

Can the FSF "Ban" Novell from selling Linux?

2007-02-09T11:01:00.000-05:00

Novell Could Be Banned From Selling Linux: Group Claims

BOSTON - The Free Software Foundation is reviewing Novell Inc.'s right to sell new versions of Linux operating system software after the open-source community criticized Novell for teaming up with Microsoft Corp.

The problem is that the FSF wants all code to be free. Period.

That's their preference, yes.

They want to make the GPL so darned viral that no one can include any copyrighted or patented components Period.

No, they want all the components on which they hold the copyrights to be protected by those copyrights. And they want those components to be freely available to anyone who agrees to make their modifications available under the same terms.

You can't modify and distribute Microsoft's code without permission. You can't modify and distribute GPL code without permission.

The way you get permission to distribute Microsoft's code is to pay them a lot of money, or cross-license your own code. They way you get permission to distribute GPL code is to release your modifications under the GPL.

Microsoft can destroy your business model by bundling a version of what you make. GPL-using authors can destroy your business model by releasing a free version of what you make.

If you don't want to be bound by Microsoft's terms, write your own code. If you don't want to be bound by the GPL, write your own code.

How is GPL viral while Microsoft is business?

How can the FSF "ban" Novel from selling "Linux" when Linux itself is not wholely licensed under the GPL and not wholely owned by FSF? Sure, there are many GPL components within the typical Linux distro, but not all of them have to be.

According to Answers.com:

More Than a Gigabuck: Estimating GNU/Linux's Size, a 2001 study of Red Hat Linux 7.1, found that this distribution contained 30 million source lines of code. ... Slightly over half of all lines of code were licensed under the GPL. The Linux
kernel was 2.4 million lines of code, or 8% of the total.

So the first point is that no, the FSF can not ban Novell from selling a GNU/Linux-based distribution, as long as all the current license terms are followed.

However, the holder of the Linux trademark, Linux Torvalds, could choose to prohibit them from using that mark to describe what they're selling. (See Micosoft / Sun / Java™) Though I haven't seen anything suggesting he plans to do so.

Next, the Linux kernel is covered under the GPL, so even if the the FSF doesn't hold the copyright it's entirely possible the kernel authors could ask the FSF to pursue any violations on their behalf. And I suspect Stallman and Moglen would be more than happy to do so.

The bottom line, I think, is that business people who don't understand the technicalities will either see a deal with Microsoft as a reason to choose Novell for any Linux plans, or they will see the controversy as a reason to avoid Linux plans altogether. Either conclusion benefits Microsoft.

People who do understand the details will see that Novell offers them a conditional, time-limited right to use a specific version of Linux, which may or may not interoperate better with Windows systems, which can be effectively "end-of-lifed" at any time by Microsoft.

And this is bad why?

2007-02-02T21:34:00.000-05:00

If you try hard enough, I suppose it's possible to spin anything into an attack on your pet target. But the consistency with which Neil McAllister sounds the call of doom and gloom for all things open source is really quite astonishing. Especially when you consider he writes the Open Enterprise column for Infoworld.

Take his January 29th column about the formation of the Linux Foundation for example:

On the surface, the union of Open Source Development Labs (OSDL) and the Free Standards Group (FSG) seems like a natural fit. Open standards and open source software are two great ideas that go great together.

But wouldn't it make more sense to call the merged organization the Open Source and Standards Lab, or the Free Software and Standards Group? Why did they have to go and call it the Linux Foundation?

On the one hand, it seems a shame that the group should narrow the scope of its activities to focus on a single project. Linux may be the open source poster child du jour, but it's hardly the only worthwhile project around.

If Neil had bothered to read his own magazine's newsletter the previous week, he would have known that:

With Linux now an established operating system presence for embedded, desktop and server systems, the primary evangelizing mission that the OSDL and FSG embarked upon in 2000 has come to an end, Zemlin said. The focus for the foundation going forward is on what the organization can do to help the Linux community more effectively compete with its primary operating system rival Microsoft.

The combination of the two Linux consortiums was "inevitable," said Michael Goulde, senior analyst with Forrester Research. "The challenge Linux faces is the same one Unix faced and failed -- how to become a single standard."

So what's wrong with focusing on Linux, anyway?

But then again, maybe it's not so strange -- not if you conclude that the Linux Foundation isn't any kind of philanthropic foundation at all. It's an industry trade organization, the likes of which we've seen countless times before. Judging by its charter, its true goal is little more than plain, old-fashioned corporate marketing.

As such, the Linux Foundation is a unique kind of hybrid organization, all right -- but it's not the union of open source and open standards that make it one. Rather, it stands as an example of how to combine open source with all the worst aspects of the proprietary commercial software industry. How noble.

This is really amazing. No one ever claimed that the partners in this merger were anything other than industry trade organizations, but the fact that the new foundation will continue the work of it's members is somehow un-noble. And nobility is the standard by which we should judge those who are trying to make Linux more competitive in the market.

His grammar and spelling may be better than that of the stereotypical Linux fanboys, who famously attack less-rabid supporters for their lack of purity. Or maybe he just has a better editor. But all the craft in the world doesn't disguise the fact that Neil's opinions are rarely more useful than the ramblings of an anonymous Usenet troll.

Changing your development platform

2007-01-25T09:30:00.000-05:00

There are certain milestones in the life of a product when developers are free to ask if it’s time to change the platform it’s developed on. Typically you’ve shipped a major version and gone into maintenance mode. Planning has started for the next version, and you wonder if you should stick with what you’ve got or if, knowing what you know now, it might be better to switch from .NET to PHP, or from PHP to Java.

You might think that checking Netcraft would be a good idea. You can see if your current platform is gaining or losing market share, and who doesn’t like market share? If you look at the latest chart you’ll see that Microsoft is gaining on Apache.

But keep in mind that while Apache's market share has gone down marginally, the total number of sites has still gone up. Most of Microsoft's gain is from new sites, not from existing sites switching. (The exception being large site-parking operations switching to IIS.)

But really the important question is whether your preferred platform faces a reasonable possibility of becoming obsolete/unsupported. This is actually one place where the Unix world's slower upgrade cycles help. You rarely have applications "sunsetted" by the manufacturer.

Am I arguing in favor of dropping .NET? Not at all. I think you should use what works for you. What I'm saying is unless your chosen platform is in danger of becoming unsupported, and that causes a problem for you, then looking at market share charts should never get you to switch.

Now if you hadn't already chosen a platform, and you wanted to know what platform had a larger market, then you'd care about market share. But that's a subject for another post.

Geeks still don't know what normal people want

2007-01-16T13:01:00.000-05:00

If you listen to geeks, locking out development of third-party applications will doom the iPhone in the market. But remember the now-famous review when the iPod was released:

No wireless. Less space than a nomad. Lame.

The market quickly decided they didn't care about wireless and bought the things in droves. And current versions have more space than the nomad did when the iPod came out. Now that the iPhone has been shown, geeks are again claiming that it's going to fail. This time because it's not going to be open to third-party applications.

Apple doesn't care if you can extend it because they believe their target customer doesn't want it extended. They want something that works well, the same way, every time. The iPod wins because it does pretty much what people want, close enough to how they want, without making them think about how to do it.

The iPhone may not be open to developers, but it's upgradable. When Apple finishes writing software to make the Wi-Fi automatically pick up a hotspot and act as a VoIP phone, that functionality can be rolled out transparently. First-gen iPhones will become second-gen iPhones without the users having to do anything.

The upgrade path will be to higher HD capacity, so people can carry more movies with them. I see these things as hugely popular for people who take trains to work. If I could take a train where I work now, I'd already be on a waiting list for an iPhone.

Principles: Deployment

2007-01-11T17:19:00.000-05:00

Code that only runs on the developer's workstation isn't finished.
Any programmer that can't be bothered with ensuring his code can be deployed is only doing half his job.
Being responsible for the integration issues caused by your code can be a real eye-opener.

Meet the new boss, same as the old boss v2

2007-01-11T16:05:00.000-05:00

Sometimes you read something that you can't summarize without losing a lot. I just can't find any extra words in this post, so here it is in its entirety:

1) Whatever language is currently popular will be the target of dislike for novel and marginal languages.

2) Substitute technology or methodology for language in #1. In the case of methodology, it seems a straw man suffices.

3) Advocates will point to the success of toy projects to support claims for their language/methodology/technology (LMT).

4) Eventually either scale matters or nothing matters. Success brings scale. An LMT is worthy of consideration only after proving out at scale.

5) Feature velocity matters in early stage Web 2.0 startups with hyperbolic time to market, but that is only a popular topic on the Web for the same reason Hollywood loves to hand out Oscars.

6) Industry success brings baggage. Purity is the sign of an unpopular LMT. The volume of participants alone will otherwise muddy the water.

7) Popularity invites scrutiny. Being unfairly blamed for project failure signals a maturing LMT; unfairly claiming success, immature LMT. Advocates rarely spend much time differentiating success factors.

8) You can tell whether a LMT is mature by whether it is easier to find a practitioner or a consultant. Or by whether there is more software written *with* or prose written *about* the LMT.

9) If you stick around the industry long enough, the tech refresh cycle will repeat with different terminology and personalities. The neophytes trying to make their bones will accuse the old guard of being unable to adapt, when really we just don't want to stay on this treadmill. That's why making statements like "Java is the new COBOL" are ironic; given time, "N+1 is the new N" for all values of N. It's the same playbook, every time -- but as Harlan Ellison said of fiction, every story has already been told, but nobody was listening the first time.

10) Per #9, I could have written this same post, with little alteration, ten, twenty or thirty years ago. It seems to take ten years of practise to truly understand the value of any LMT. Early adopters do play the important role of exploring all the dead ends and limitations, at their cost. It's cheaper to watch other people fail, just like it hurts less to watch other people get injured.

11) Lisp is older than I am. There's a big difference between novel and marginal, although the marginal LMTs try to appear novel by inserting themselves into every tech refresh cycle. Disco will rise again!

12) If an LMT is truly essential, learning it is eventually involuntary. Early adopters assume high risks; on the plus side they generate a lot of fodder for blogs, books, courses and conferences.

13) I wonder if I can get rich writing a book called Agile Lisp for Web 2.0 SOA. At least the consulting and course revenue would be sweet. Maybe I can buy an island. Or at least afford the mortgage payments on a small semi-detached bungalow in the Bay area.

14) It requires support from a major industry player to bootstrap any novel LMT into popularity. The marginal LMTs often are good or even great, but lack sponsors.

15) C/C++ remain fundamental for historical reasons. C is a good compromise between portability and performance -- in fact, a C compiler creates more optimal code than humans on modern machine architectures. Even if not using C/C++ for implementation, most advocates of new languages must at least acknowledge how much heavy lifting C/C++ does for them.

16) Ditto with Agile and every preceding iterative methodology. Winding the clock back to waterfall is cheating. I'm more sophisticated than a neanderthal, but that won't work as a pick up line.

17) Per #13, I don't think so, because writing this post was already a chore, let alone expanding the material to book length. Me an Yegge both need a good editor.

Borealis
Sunday, January 07, 2007

This covers the technology pretty well. All he left out was the reason so much is coming back.

Get your boxes in order

2007-01-11T12:50:00.000-05:00

Everyone seems to have an opinion on downloading music and TV shows, everything from "Information wants to be free" to "Skipping commercials with your TIVO is theft." Some of the views are self-serving, some are rationalizations, and some people have strong opinions based on what they believe is right and just.

Here's the thing a lot of people are missing, though: Breaking the law does not count as civil disobedience unless you go out of your way to do it publicly. Obviously I'm referring to people who upload and download music, movies or software without permission from the copyright holders. Some of them are just in it for the free tunes. Some of them think the law is wrong. But the ones who believe copyright laws have gone too far damage their case when they quietly violate the law, expecting to protest the law if they are caught.

Think the law has tilted too far in favor of the copyright industry? Great, so do I. Have you written to your congressman? If not, then don't complain about the law when you get busted. It makes it look like you're just trying to stay out of jail -- which you are -- and supports the MPAA and RIAA next time they try to get copyright extended.

Before you end up in a jury box, you should really try the ballot box. Time for me to get off my soapbox.

What is Steve Jobs thinking?

2007-01-11T09:32:00.000-05:00

We all knew Cisco had the trademark on the name. According to their press release:

"Cisco entered into negotiations with Apple in good faith after Apple repeatedly asked permission to use Cisco's iPhone name," said Mark Chandler, senior vice president and general counsel, Cisco. "There is no doubt that Apple's new phone is very exciting, but they should not be using our trademark without our permission."

They negotiated, Cisco said no. So they release it anyway. And Apple's response is:

Apple responded by saying the lawsuit was "silly" and that Cisco's trademark registration was "tenuous at best".

"We think Cisco's trademark lawsuit is silly," Apple spokesman Alan Hely said. "There are already several companies using the name iPhone for Voice Over Internet Protocol (VOIP) products."

It's "silly"? Come on, that sounds like they're daring Cisco to take it to court. And claiming that the trademark has already been diluted by other products is a dangerous game. If that argument prevails, then Apple will have no standing to prevent anyone else from releasing their own iPhone.

What the hell are they thinking?

[Update]

See the Joel on Software forums for some discussion of this.

Pay the man

2007-01-10T15:56:00.000-05:00

IT people are frequently highly-educated, with extensive formal and on-the-job training. And we all, if you look at our resumés, think that we're fast learners. That's probably because everything we work with keeps changing every couple of years, so anyone who's been doing this for very long has learned multiple generations of tools. Many of our jobs also require us to be generalists, with a broad range of knowledge across multiple unrelated fields.

It's probably not surprising, then, that we tend to be DIYers. Never changed a light fixture? No problem. Give me a few minutes with a book and I'll know enough to do it. House needs painting? Heck, I've always wanted an excuse to go get one of those power sprayers, I'm on it! That's why we're shocked to hear how much people pay to have someone do work that, after all, we could do ourselves with little or no training.

That was my frame of mind when I had to replace the shower door. The frame was mounted on tiled walls. I only cracked two of the tiles a little bit trying to get the old frame off, and lifted about a dozen away from the wall. No problem, just ran to the hardware store for some tile adhesive. And I only put the adhesive on a little too thick, so two of the tiles fell off the next day when I started mounting the frame. And I only cracked one more because I was unfamiliar with the mounting hardware.

I had to remove all the tiles and start over because the adhesive was actually nowhere near dry. I wanted to make sure it dried all the way, because I wasn't completely sure I did it right this time. When I tried again three days later, there was only one tile that fell off because I had gone too thin with the adhesive. But after waiting a day for the grout on the rest to dry, I was able to scrape that space out and get the last tile up and grout it. The caulk and grout I used to patch the cracks looks mostly okay ... for now ... while it's still white

All in all, it only took me a week and a half to hang that door. And the cracked and patched tiles will probably still look good when I go to sell the house. (At least I hope they will; the color was discontinued years ago, so I'd have to re-tile the whole damn bathroom otherwise.) I'm so glad I didn't pay a hundred bucks to some barely-trained tradesman to do it for me.

Lipstick on a pig

2007-01-10T11:22:00.001-05:00

If you've ever seen one of my project plans, there's a chance you've seen a task at the end that says "Add pretty". With good use of stylesheets, you can radically improve -- or damage -- the look of a website even after all the coding and most of the testing are done. A different person or group with a different skill set can take over from the programmers and work some magic with little interaction.

You might think, based on this, that other parts of development can be pushed to the end after "real" development is done. You'll know someone was thinking that when you see a task late in a project plan that says "Add fast".

I suppose I can live with the idea that there will be some performance tuning that's best done once everything else is complete. And on some projects just throwing more hardware at the problem is cheaper than a programmer's time to fix it. But actually improving the performance of an application is hard, and the changes pervasive.

The second manifestation of specialized groups, one that always raises the brown flag, is when I see "Add security" at the end of a plan. It's simply inexperience that allows anyone to think they can graft a security model onto a codebase after the fact without significant amounts of rewriting.

"But this is a quick hack, and we only need the numbers for this one meeting." Sure, a report you'll only ever need once. I guess such a thing could exist, but I've never seen it. In the first place, nothing lasts as long as a temporary fix that works well enough. And in the second place, many (most?) large, successful products started out as small, successful products.

End/begin dependencies look really great on a Gantt chart. Activities that invite and incorporate feedback don't look so neat and clean. Treating security as something that can happen to a product after it's already done is no better than ... well, see the title of this post.

Design = function + aesthetics

2007-01-10T11:04:00.000-05:00

Ask your local programmer if he knows how to design user interfaces and invariably he'll say he does. Go ahead, ask. I'll wait.

...

You're back? Good. Now go look at the new iPhone. Has your guy ever made anything remotely that cool? Unless you're reading this from Cupertino, odds are he hasn't. The UI is more beautiful and, as near as I can tell from the demo movies, more usable than any other phone or music player I've seen. But I wonder, how much of the perceived usability is a response to the beauty?

It's becoming conventional wisdom that you don't want to make the demo look done. Excessive visual polish early in the process not only limits the feedback you get to comments about the superficial details, it also suggests equally finished interaction with the system. It literally makes it look like it's doing more than it really is doing.

I've avoided this problem in my career by not being very good at graphics, and avoided realizing that by not working with any real visual artists to compare my work to. Yes, I used to think I was good at it, just like every programmer. Eventually I realized that consistency and predictability were a poor subset of what an artist can add.

Now, whenever I make up a project plan, there is a task at the end for "Add Pretty". And my name isn't on that task.

The Digital Dark Ages

2007-01-09T15:39:00.000-05:00

I've been paying my mortgage for about three years now. Unless I change something, I'm going to keep paying on it for another 27 years. I try not to think about the fact that although I have an actual physical copy of the mortgage agreement, with real pen-and-ink signatures, I don't have any proof that I've ever made a payment.

At the risk of sounding like a Luddite, it bothers me that I have to trust the bank's computer system to keep track of all 360 payments I'll have made by the time it's over. I'm not just being paranoid. I had an issue where a bank said my wife still owed money on a loan we had paid off three years earlier. We didn't have anything in writing for each payment. The bank couldn't even tell us the history of the loan; just that the computer showed we still owed money. And if a bank says you owe money, unless your lawyers are bigger than their lawyers, then you owe them money.

If you go to museums, you'll see ledgers from banks in the 1800s and earlier. Over two hundred years later and we still know who paid their bills and when. But five years in the past ... it doesn't exist.

This could change with new regulations and retention requirements. But the big difference is what is standard vs. what you have to work at. A hundred years ago everything was written down. If you wanted to get rid of records you had to make an effort to identify what you wanted to delete, somehow separate it from the rest, and physically destroy it. Today, we only keep data as long as we have to. We only bother with long-term storage when the law or financial necessity makes us.

Let's assume we have some data that we really want to keep "forever". What is that going to take?

First, you'll want to store it on something that doesn't degrade quickly. Burning it to a CD or DVD seems to offer better longevity than VHS. Well, maybe. Second, you want to store it in a format that you'll be able to read when you want to. This might be a harder problem than the physical longevity, when you start to consider how much data goes into a modern file format.

Look at the problem from the user's perspective: The document format (the same applies to music and video) is just a way of saving the document in a way that it can be opened and look the same way at a later time, maybe on the same computer maybe not. When Windows 97 handles table formatting and text reflow around images a certain way for instance, the document format has a way of capturing the choices the user made.

If I open that Word 97 document in Word 2003, either the tables, text and images look the same or they don't. If they look the same, it's because there's an import filter that understands what the old format means, and Word 2003 has a way of representing the same layout. If I then save as Word 2003, while the specific way to represent the layout has changed, the user doesn't see the difference nor care.

If, on the other hand, that Word 97 document doesn't look the same in Word 2003, it really doesn't matter to the user if problem is a bad import filter or if Word 2003 doesn't support the same features from Word 97. (Maybe they used flame text.) So a format that technically captures all the information needed to exactly recreate a document is utterly useless without something that can render it the same way.

Okay, so we need long-term media, and we need to choose a format that is popular enough that there will still be import filters for it in the foreseeable future. Eventually we'll still reach the end of those paths. Either the disks will degrade, or the file format will be so out of date that no one makes import filters any more. When that happens, the only way to keep our data will be to copy it to new media, and potentially in a new format.

What should that format look like? We've already got PDF, which is based on how something looks in print. We've got various audio and video formats, which deal with playing an uninterrupted stream. But what about interactive/animated documents designed for online viewing?

Believe it or not, I'm going to suggest a Microsoft solution, though it's one they haven't thought to apply this way: PowerPoint. Today nearly everyone has a viewer, but not so long ago most of the slideshows I got were executables. If you had PowerPoint installed you could open the executable and edit the slideshow the same way you can edit a PDF if you have Acrobat.

As much as people complain about the bloat that Word adds to simple files, I think the future of file distribution will be to package the viewer along with the file. At some point storage becomes cheaper than the hassle of constantly updating all those obsolete file formats. The only question is how low a level the viewers will be written to: OS family, processor architecture, anything that runs C, etc.

Meet the new boss, same as the old boss

2007-01-08T17:26:00.000-05:00

In case you haven't noticed yet, we're going through another round of power struggles in the IT industry. Oh, that might not look like what's going on. On the surface what people are saying is that it's a matter of web-based vs. desktop applications. Frequently these conversations are based on the premise that it's a discussion of the technical merits.

Nope. It's the return of the glass house. Peel back all the rationalizations about easier deployment, easier support, more consistency, and what it really comes down to is more control. If we can just keep the software out of the users' hands then everything will be okay.

But what history shows us is that users like having control of their "stuff". Taking that control away requires either redefining "their stuff" to be "our stuff", or convincing them that they aren't qualified to handle their stuff.

Is this what your customers are hearing from you?

The War on Laundry™

2007-01-07T20:48:00.000-05:00

Let's see:

Not a finite thing that can be destroyed, nor group which can be defeated.
No one qualified to declare surrender for it.
There are better and worse ways to deal with it, none of which are able to completely eliminate it.
No matter how much you fight it, there will always be more soon.
No one really likes it, but the only way to avoid it is to change your lifestyle so profoundly that the alternative is worse.

Hmm, sounds about right.

Any relation to other Wars on Nouns are completely intentional.

The day I got a lot smarter

2007-01-05T11:13:00.000-05:00

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.

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 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.

No matter how urgently someone says they need an answer, the wrong answer won't help.
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.
If you didn't create the problem, always give the person who did the first chance to fix it.
If someone knows more about a topic than you do, have them check your work.
Don't make important decisions on too little sleep.
Before making a presentation to a client, review the materials with your co-workers.
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

2007-01-03T11:31:00.000-05:00

"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

2007-01-03T09:51:00.000-05:00

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.

The 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

2007-01-02T14:57:00.000-05:00

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

2006-12-27T16:35:00.000-05:00

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 prefernce 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:

Users, for some reason, think that they should do the very thing we're telling them not to do.
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

2006-12-27T12:55:00.000-05:00

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

2006-12-21T16:00:00.000-05:00

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

2006-12-21T12:02:00.000-05:00

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?

2006-12-21T09:39:00.000-05:00

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 ...

2006-12-20T16:24:00.000-05:00

... 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 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"

2006-11-29T16:55:00.000-05:00

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.