“What kind of work do you do?” someone asks you.
“I’m a web developer,” you reply.
“How interesting! What site do you work on?”
“It’s just a small site. You wouldn’t have heard of it.”
“Oh I’m on the web a lot. I may have seen it. What’s it called?”
In a barely audible voice, halfway between a mumbling cough and a coughing mumble, you say, “DogPoopBags.com.”
“Ha ha ha — for a second there I thought you said DogPoopBags.com. I . . . uh . . . oh, sorry.”
Infomaki is an open source “lightweight” usability testing tool developed by the New York Public Library to evaluate new designs for the NYPL.org web site and uncover insights about our patrons. Designed from the ground up to be as respectful of the respondents’ time as possible, it presents respondents with a single question at a time from a pool of active questions. In just over seven months of use, it has fielded over 100,000 responses from over 10,000 respondents.
Look me in the eye
Then tell me that I’m satisfied
Hey, are you satisfied?
What is a reasonable target for user satisfaction with a web site?
We did a user satisfaction survey last year and found that 14 percent of respondents felt that our web site didn’t measure up to their expectations.
This year, we have an incentive goal of reducing that number to 8 percent, not based on evidence that any web site has ever achieved a number that low, but based on the opinion of the company that did the survey that anything over a 10 percent dissatisfaction rating is always bad.
Or to flip it around, we’re trying to achieve a 92 percent approval rating.
I wish we hadn’t set the bar quite that high. I don’t want to be a pessimist but not only is that considerably higher than, say, Google (at 78 percent — and what’s not to like about Google?), it’s also higher than Santa Claus, crack cocaine and oral sex . . .
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
We’re discussing whether our organization will use a popup user survey on our web site . . .
“I propose doing the survey without the popups,” I say. “That’s why browsers have popup blockers, because people don’t like popups. A popup is like a poke in the eye. I don’t like it when things pop up unexpectedly and poke me in the eye. Whenever that happens, I make sure not to go back to that place anymore.”
Unfortunately, no one picks up on the “popped up and poked me in the eye” motif because I was then going to chide them for their junior high school mentality.
“I had a teacher who used to say that,” a young woman says. “‘It’s better than a poke in the eye with a sharp stick.’”
I say, “I used to work with a guy who said, ‘You can’t beat that with a sharp stick.’ Why would the stick have to be sharp if you’re going to beat someone with it? You’re really just looking for something with a little heft to it.”
The same woman says, “I had a boyfriend who used to say, ‘You’re not going to hold that over my shoulder, are you?’”
“You have abysmal taste in men.”
I wasn’t able to persuade the team to abandon the popups. The argument in favor was that a lot of web sites use popup surveys so how bad can they be?
I worked for a dot-com consulting company during the boom and bust of that industry. The whole thing was based on the notion that everyone else is doing it so it must be a good idea.
The subsequent implosion of the entire industry disproved that theory rather dramatically.
Since then, I try to stay open to the possibility that even though a lot of people are doing something, it still may not be a good idea . . .
Thus spoke The Programmer.
. . . when public website users perform simple Internet tasks, they’re successful two-thirds of the time on average. In other words, users fail 35% of the time . . .
Six sigma tolerates no more than 3.4 defects per million manufacturing opportunities; in contrast, the Web generates 350,000 defects per million interaction opportunities. The difference between the two quality levels is a factor of 100,000.
The only reason the Web works at all is that people are flexible and persistent enough to try again when their first attempt fails.
The good news, I suppose, is that the opportunity for improvement is virtually limitless.
Thus spoke The Programmer.
Best one-sentence explanation of how the dot-com boom killed professional practice in the software business:
Improving operational efficiency is not a priority during gold rushes.
In high school, I was in the school orchestra. There were no auditions; it was just a class you could sign up for, independent of whether or not you had any musical ability.
And when a student with no musical ability signed up for the orchestra, what transpired was something like this:
Director: What instrument do you play?
Student: I don’t really play an instrument.
Director: You’re in the percussion section.
There were three or four of us in the percussion section who could actually read music and play it, so it was kind of depressing that it was mainly a backwater where musical illiterates were sent to bang on cowbells . . .
I recollected my days as a high-school percussionist today when one of our tech leads — tech leads — pulled up some javadocs and announced that a method we were using was “depreciated.”
Now if this cretin is not familiar with the term “deprecated” — which he certainly should be — but since he isn’t, you’d think he might at least be capable of reading or sounding out his own language.
But no such luck there either.
Ever since the dot-com boom wiped out the hiring standards for the software business, this is what’s become of a once-noble profession.
Clang! Crash! Boom!
Thus spoke The Programmer.
The big controversy at the office this week was a “radical” idea offered by one of our developers regarding data collection with a series of web-based forms.
The idea was that rather than just pouring the data into a relational database like everyone else does, we’d build up an XML tree, essentially a gigantic (in this case, ~200K) string, and pass that around from form to form.
The advantages of this, if I understood correctly, would be to simplify the data model design and eliminate the need for table joins.
Of course, it also violates every known rule of efficient data access and ratchets up the processing requirements by several orders of magnitude, but that didn’t stop one of the development managers from throwing his full-fledged support behind it.
I TA’ed undergraduate software engineering classes for a year at USC, and every so often an underclassman would advance some “radical” theory on how a programming problem ought to be solved, unaware of the fact that their proposed approach had actually been discredited 15 years earlier.
That’s okay . . . by the time they completed their degree, they usually had a much better understanding of the history and foundation of their discipline.
But the advent of web development has brought us a new generation of programmers, many of whom have not had the benefit of a formal education in computer science, which leads to sophomoric programming strategies being proposed by “professional” developers . . .
Thus spoke The Programmer.
Resemblance to persons living or dead is statistically probable.
Name: Snopes, Flem
Title: Software Development Manager
| Developing Others |
|
Flem was not effective in giving team members an opportunity to be successful or to do high-quality work. The project development process was limiting and frustrating.
Rating: Did Not Meet Expectations |
| Integrity |
|
Good work ethic. Big problem here is that Flem didn’t seem to see how poor project outcomes were a direct result of anything he did or didn’t do. He seemed to feel that he was a victim primarily of bad technology, as well as bad clients, bad luck, bad karma, etc. And while there were some unavoidable setbacks on the project, as there are on any project, Flem didn’t seem to see the human decision points in the process where he could have made a difference.
Rating: Met Some Expectations |
| Change Management |
|
Flem was slow to react to changing circumstances. He took a “stay the course” approach and continued to pursue strategies long after they had proven ineffective. Rating: Did Not Meet Expectations |
| Communication |
|
Flem is an articulate communicator but does not seem to be effective in reporting bad news to clients and upper management. He has a “can do” communication style that unfortunately keeps people in a state of total denial about what’s actually happening. As a result, what could have been modest setbacks, had they been acknowledged as such and dealt with, escalated into full-blown breakdowns. Rating: Met Some Expectations |
| Customer Service/Responsiveness |
|
Flem was probably overly responsive to customer requests, with a resulting boomerang effect. He took client requirements at face value and did not provide the kind of risk management one would expect from a responsible professional. As a result, most of the client’s investment in web development was wasted on non-productive activities.
Rating: Met Some Expectations |
| Leadership |
|
Flem maintains a positive attitude when things aren’t going well. Unfortunately, his projects never seem to be going well. He failed to fulfill the main role of a project leader, which is to monitor plan vs. actual and to take action as needed to bring the two closer together. In some cases, a project manager fails to observe that a project is veering off course, but I don’t think that was the case here. I think Flem just failed to act on that observation.
Rating: Met Some Expectations |
| Performance Effectiveness |
|
Flem did not establish any sort of professional quality standards for the project, resulting in a considerable waste of time, money and human potential. He did not demonstrate the ability to effectively steer a software project.
Rating: Did Not Meet Expectations |
| Problem Solving/Judgment |
|
Flem advocated a fairly random approach to problem solving. When dealing with system errors, rather than attacking root causes, we took some random action hoping that would fix the error. Sometimes it did, although we didn’t know why. Sometimes it didn’t. Sometimes it introduced a new error. This is an area where a technical leader needs to take a stand and do the right thing.
Rating: Did Not Meet Expectations |
| Team Orientation |
|
I think Flem’s failure to establish professional quality standards had a disheartening effect on the team. People will work hard to achieve excellence, but not if they see that management places no value on it.
Rating: Did Not Meet Expectations |
| Technical Expertise |
|
Flem has some very good technical skills, but did not exhibit a good understanding of the full range of technical options, risks and tradeoffs involved in developing a web application.
Rating: Met Some Expectations |
Thus spoke The Programmer.
I’d never heard of TheMan.com until yesterday, when I read that the site had shut down, and replaced what I assume must have at one time been content with the resumes of its out-of-work former employees.
You can get a good feel for the company from this Sept. 27, 1999 Time magazine article.
Cringe in horror as moronic 27-year-old CEO Calvin Lui closes meetings by barking “All right, dudes, let’s rock and roll!’
Gasp in amazement as he draws analogies between TheMan.com and one of his former employers, the Walt Disney Company! “This could be a major, major public company,” he says. Not a major public company, but a major major public company!
Feel his soul-stirring passion to recruit “the A people” for”‘below-average salaries”!
Lui was right about one thing though: “I understand that right now we’re a zit compared to everybody else. But in a year, we’re not going to be a zit.”
What did he think they were going to be? A cyst? An abscess?
Well, no matter. The important thing is that now you — yes, you! — can duplicate Lui’s spectacular results by adding some of his underpaid A-Team to your own staff.
Act quickly!
Are you looking for a Lead Web Developer? Consider William Huang. According to his resume, Huang held the title of Lead Web Developer at TheMan.com, Inc., for the past year.
He has no other programming experience, but he does have 4+ years of service as Assistant Manager at the Corridor Center 55 shopping center, where his responsibilities included:
So if you need a Web developer who can also sweep up, look no further.
Huang’s resume lists no educational background, but that has not prevented him from achieving proficiency with WS_FTP Pro. That will come in handy if you have a need to move files around from one server to another, as many companies do!
His resume also states that he plays both basketball and volleyball, if you ever need to get up a game.
I don’t know who said that. But I know there was a time not too long ago when you couldn’t even get hired as a trainee in this business without at least having a college degree.
Of course, at that time no one really believed you could hire “A people” for below-average salaries.
Serious, responsible companies lived or died with their data, so they hired serious, responsible people to work with it, and they paid them an appropriate wage.
Tempora mutantur nos et mutamur in illis. The times are changed even as we are changed in them.
Thus spoke The Programmer.
Most of my illustrious career has been spent working or consulting for Fortune 1000 companies. These companies are fundamentally dependent on their computer systems, particularly their online systems, to transact business.
If the systems are down, the business stops running.
In fact, the systems don’t even have to be down to create havoc.
What if the response time is too slow? If you’ve ever done user testing with people whose job it is to enter money-making financial transactions for large corporations, you may have been amazed, as I was, at how fast they are.
Obviously then, the software you build for them has to be even faster; split-second response time is required. If your software is slowing people down, the business is losing money.
Or what if people are sitting around staring at their monitors because they can’t figure out how that great new interface you gave them is supposed to work?
Bad news.
Again there’s a measurable loss of revenue. Because these people are not supposed to be staring at their monitors, they’re supposed to be entering those money-making financial transactions, remember?
I could go on with this, but I think we both get the point: As a technologist working with these companies, you’re held to an exacting standard, because the cost of failure is high.
One evening many years ago, I put a software upgrade into production for a client, a major electronics distributor.
It was a pretty straightforward upgrade and we tested it, but I guess we didn’t test it diligently enough on certain boundary cases, because when I came in the next morning, I was informed that our “upgrade” had crashed, preventing the online system from coming up for an hour until it could be backed out and order was restored.
In other words, we had effectively put the company out of business for an hour, a really expensive mistake. I was further informed that the CIO wished to talk with us in his office once he was finished getting his ass kicked by executive management.
Well, my dick was limp, I’ll tell you.
I took a moment to divide the company’s annual revenue by the number of business hours in a year. According to my calculations, this fiasco had cost about $250,000.
I popped another Xanax and washed it down with a pot of coffee to keep from passing out. I was twitching like a chicken for hours.
Yes, and thanks to experiences like that, I now consider myself a seasoned developer. I try to anticipate the consequences of technical decisions early in a project in an effort to avoid downstream catastrophes.
But I don’t work on mission-critical applications now.
I work on Web applications.
And with different kinds of applications come different kinds of developers.
Most Web developers have worked exclusively on systems where the cost of failure is very low, so they rarely ponder the implications of technical decisions in great detail.
Why bother? What’s the worst thing that could happen?
Well, the Web site could have unpredictable access times, it could scale poorly, users could be unable to navigate the interface.
But so what?
As I write this, people still expect Web sites to have unpredictable access times, to scale poorly, and to have confusing interfaces.
Developers aren’t penalized for this; it’s all factored into the equation, as though improving the situation is beyond human capacity.
He who pays the piper is calling for a low-quality tune.
Okay, part of the problem is that most clients either don’t know any better or aren’t willing to pay for better.
And, you might say, why should they when users are still more than willing to forgive them for mediocrity?
But here’s the real problem:
Very few Web developers have had the edification that comes from blowing away a quarter of a million dollars of someone else’s money in an hour, not to mention the resulting shitrain that descends over the land.
Because if they had, they’d be a little more careful next time.
Here’s a fun story about the benefits of really holding people accountable for shoddy workmanship.
In The Innocents Abroad, Mark Twain wrote about King Xerxes, who in the 5th Century BC ordered a bridge of boats to be built across the Hellespont:
A moderate gale destroyed the flimsy structure, and the King, thinking that to publicly rebuke the contractors might have a good effect on the next set, called them out before the army and had them beheaded. In the next ten minutes he let a new contract for the bridge. It has been observed by ancient writers that the second bridge was a very good bridge.
Res ipsa loquitor.
Thus spoke The Programmer.
